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spends, even within a probabilistic framework. In another 
embodiment, the micropayment scheme includes a deferred 
selection protocol, which provides the bank with control 
and flexibility over the payment selection process. 
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METHOD AND SYSTEM FOR MICROPAYMENT TRANSACTIONS 
Cross-Reference to Related Applications 
This application claims benefit of priority to: 1) U.S. Provisional Application Serial No. 
60/287,251, entitled "Method and System For Micropayment Transactions" and filed on April 
27, 2001; 2) U.S. Provisional Application Setial No. 60/306,257, entitled "Method and System 
for Micropayment Transactions" and filed on July 18, 2001; and 3) U.S. Provisional Application 
Serial No. 60/344,205, entitled "Method and System for Micropayment Transactions" and filed 
on December 26, 2001; all of which are incorporated by reference herein in their entireties, as if 
fully set forth below. 

Background 

The growth in electronic commerce systems has led to a rapid growth in the number of 
financial transactions taldng place across electronic networks. Micropayments aiable new fomas 
of electronic commerce transactions, by providing a convenient method for financing on-line 
low-value services such as information retrieval services. Miaropayments may have very low 
value - in some cases fractions of a penny - but may be executed in very high volumes. By way 
of example, information service providers may wish to charge for their services in small 
increments. Micropayments may be used to pay for each web page visited or for each minute of 
music or video streamed to the Tiser. 

A simple form of an electronic payment scheme is an electronic check. An electronic 
check consists of a check that is digitally signed, rather than hand-signed. A digital signature 
allows the receiver of the check to verify both the authenticity of the signing party, and the 
integrity of the contents of the check (e.g., the date and amount of the check). The Uterature on 
public key cryptography provides many methods for implementing digital signatures, such as 
the RS A method described m "A method for obtaining digital signatures and public-key 
cryptosystems," Rivest, R.L., Shamir, A., and Adleman, L.A., Communications of the ACM, 
Vol. 21, No. 2, 1978, S. 120-126. As is well known, each party in a pubUc key cryptcsystem 
uses a unique pair of keys. Each pair includes a public key and a corresponding private (or 
secret) key. WhUe the public key is made available to the public, the corresponding private key 
is known and accessible only to the owner, who safeguards it and keeps it secret. It is not 
computationally feasible to derive the private key fiom the knowledge or discovery of the 
corresponding pubUc key. Therefore, making a pubhc key available to the public does not 
endanger the security of the matching private key. Because a private key is never accessible to 
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anyone but its owner, public key cryptosystems enjoy an increased security, as compared to 
systems in which secret keys are shared among different parties. 

In a public key cryptosystem, a sender who wishes to secretly send a message obtains the 
receiver's pubUc key and uses it to encrypt the message. Upon receiving the encrypted message, 
the receiver uses his matching private key to decrypt it and read the original message. Without 
access to the matching private key, it is computationally infeasible to decrypt the encrypted 
message. 

In a public key digital signature scheme, a signer of a message creates his digital 
signature by applying his private key to the message. The resulting digital signature is thus 
unique to both the message and to the particular private key used to create the digital signature. 
Auyone in possession of the message and the digital signature can verify the authenticity of the 
digital signature using the signer's public key. 

A hash function is also used in many pubUc key digital signature schemes. A hash 
function is an algorithm which, when appUed to a message, creates a digital "fingerprint" of the 
message, in the form of a "hash value" that typically has a fixed length. A "one-way collision- 
resistant" (or secxire) hash function is a hash function for which it is computationally infeasible to 
derive the original message from its hash value, or even to fmd two messages having the same 
hash value. The hash of a message thus works well as an identifying "fingerprint" for the 
message, since if one makes any change, even the sUghtest change, to a message, one invariably 
obtains a message with a different hash value. 

It is common to use hash functions in digital signature schemes in a "hash and sign" 
mamier. To create a digital signature in this way, the sender of a message applies a hash function 
to the message, thus computing a message digest or hash value for the message. The sender then 
applies' his private key to the hash value to obtain his digital signature for that message. 

The authenticity of the digital signature, as well as the integrity of the contents of the 
message, can be verified using the sender's pubUc key and the hash fimction that was used to 
create the signature. The receiver can verify that the message was indeed signed by the sender 
by recomputing the hash value for the message, and then applying a verification procedure that 
takes as inputs this hash value and the sender's pubHc key. The verification procedure might 
say, for example, to use the sender's pubUc key as a decryption key and to accept the signature as 
valid if the decryption yields the recomputed hash value of the message. If verification succeeds, 
the receiver may be confident that the sender actuaUy signed the message and that the message 
was not altered since it was signed. 
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In a typical electronic check payment scheme, a user pays a merchant for a transaction by 
providing a digital signature to a piece of data that identifies the transaction. The data may 
identify, among other things, the user, the user's bank account number, the merchant, the amount 
to be paid, the time of the transaction, and/or the information, services, or merchandise that has 
been purchased. Typically, the merchant deposits the electronic check that he receives firom the 
user by sending the check to the bank. 

The digital signature capabilities in an electronic check scheme may be siq>ported by 
digital certificates. A digital certificate is most commonly an electronic docxmient that asserts 
that a particular individual holds the private key corresponding to the public key given in the 
certificate. In other words, the certificate correlates a key pair with a particular party. Since the 
certificate is itself digitally signed by a trusted authority, a digital certificate is normally trusted 
as proof that the named party indeed owns the public key listed in the certificate and that the 
named party exclusively controls the corresponding private key. Digital certificates may also 
assert that the party is authorized to sign electronic payments or perform other specified actions. 

After verifying the digital signature on an electronic check, the bank may credit the 
merchant with an appropriate amount, and may debit the user with an appropriate amount. The 
bank may also charge discretionary transaction fees or other fees. 

Electronic payment systems, and in particular micropayment systems, face many 
challenges. A fimdamental problem with micropayments lies in a bank's processing costs for the 
micropayments. Frequently, the cost to the bank of handling a micropayment transaction will be 
many times larger than the value of the micropayment itself For example, processing a credit 
card transaction usually costs about 25 cents, while a typical micropayment may be worth about 
1 cent or less. Exceptional efficiency is therefore required in order to support micropayments; 
otherwise the cost of the payment mechanism will much exceed the value of the payments. 

Micropayment schemes therefore attempt to reduce the bank's processing costs by 
aggregating many small payments mto fewer, larger payments. A variety of aggregation 
strategies are available. Some micropayment schemes have session-level aggregation: all 
payments between a user and a merchant during a given "session" are aggregated into a single 
larger payment Another strategy is global aggregation: payments are aggregated across all 
user/merchant pairs. Global aggregation can provide greater flexibility and greater cost savings. 

A number of micropayment schemes are known in the art, and surveys can be found in 
the literature, for example in "Digital Cash: Commerce on the Net," Peter Wayner, Academic 
Press, 1996. Micropayment schemes that are currently known include "PayWord" (described in 
"PayWord and MicroMint: Two shnple micropayment schemes," Ronald L. Rivest and Adi 
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Shamir, Fourth Cambridge Workshop on Security Protocols, Springer Verlag Apr. 1996), and the 
"electronic lottery scheme" (described in "Electronic Lottery Tickets as Micropayments," Ronald 
L. Rivest, in Proceedings of Financial Cryptography '97, vol. 1318 of Lecture Notes in Computer 
Science, pp. 307-314, Springer 1997). Other known micropayment schemes include, but are not 
limited to, "Millicent" by Manasse et al., "MicroMint" by Rivest and Shamir, "NetCard" by 
Anderson, "PayTree" by Jutla and Yung, "MicroiKP" by Hauser et al., the probabilistic polling 
scheme by Jarecki and Odlyzko, a proposal for "transactions using bets" by Wheeler, a similar 
proposal by Pedersen, and a related proposal for micropayments by efficient coin-flipping, by 
Lipton and Ostrovsky. The Jarecki/Odlyzko probabilistic polling scheme is disclosed in U.S. 
Patent No. 5,999,919, entitled "Efficient Micropayment System," and issued to Stanislaw Jarecki 
and Andrew M. Odlyzko on December 7, 1999. 

PayWord is a micropayment system based on public key digital signature schemes and 
one-way hash-functions. In the PayWord system, a user receives from a bank a digital 
certificate, which authorizes the user to make chains of hash values, or "paywords" Wi. These 
paywords can be monetarily redeemed from the bank by the merchant. The f-th payword is 
related to the i+l-th payword by the relation: 

Wi = h(wi+i), 

where h is a one-way hash function. Thus it is computationally infeasible to derive Wj+i from 
h(Wi+i). The i+l-st payword Wj+i can be verified by the merchant using the i-th payword Wi , by 
performing the hash operation h on Wi+i. In the PayWord scheme, the user computes a chain of 
hash values, Wo, Wi, . . . , Wn, and commits to the entire chain by sending his digital signature of 
the root Wo to the merchant. Afterwards, the user makes each successive payment to the 

merchant by revealing the paywords consecutively in turn (wi, W2, . . Wi, ). Each 

consecutive value in the chain can be verified by the merchant, by performing the hash function 
on that value in order to check that it hashed to the previous value in the payword chain. 

PayWord allows the merchant to conveniently aggregate the buyer's payments. After k 
micropayments have been made, if the merchant feels that, taken together, the k micropayments 
constitute a sizable enough macropayment, the merchant makes a single deposit in the bank for k 
cents (or other appropriate monetary units that represents each micropayment). The vendor 
reports to the bank only two values, Wk, and the user's signature of wo- The bank verifies the 
user's signature of wo, and iterates the hash function k times on Wk, to verify that this operation 
does indeed yield Wq. After verification, the bank pays k cents into vendor's account, and 
charges the user's account k cents, and charge other transaction fees at its discretion. 
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PayWord suffers from the disadvantage that the merchant caimot aggregate 
micropayments of different users. This is because in PayWord, each user must estabUsh his own 
hash-value chain with the merchant, and because different hash-value chains cannot be merged. 
Many other micropayment proposals, such as MilUcent, also suflfer from this problem of not 
being able to aggregate micropayments across different user/merchant pairs. That is, PayWord 
only provides session-level aggregation, not global aggregation. 

The electronic lottery scheme by Rivest provides another method for aggregating 
micropayments, so as to reduce transaction costs. This scheme is based on a selection rate or 
selection probability s (0<s<l) for each micropayment: on average, only one out of every 1/s 
nricropayments is selected for actual payment The selection rate s is known, predictable, and 
fixed. For each micropayment presented to the merchant, the merchant first verifies the user's 
signature on the root wo of the PayWord chain and verifies that the provided hash value Wk 
indeed yields wq when iteratively hashed k times. If so, the merchant accepts the micropayment 
from the user. The merchant then goes through a predetermined interaction protocol with the 
user, in order to determine whether or not the micropayment should be selected for deposit at the 
bank. A non-selected check can not be deposited and is thus worthless to the merchant; it is thus 
discarded by the merchant. Only a micropayment that is selected (through the interaction 
protocol) is actually presented to the bank by the merchant, in order to receive payment. In this 
way, the bank does not have to process each and every micropayment, but only processes, on 
average, one out of 1/s micropayments. The bank's processing costs are thereby greatly reduced. 
To make this process fair to the merchant, for each selected micropayment, the merchant gets 
paid an amount 1/s times greater than the originally specified micropayment amount In other 
words, the bank pays to the merchant an amount that is "scaled" to a value 1/s times the face 
value of the micropayment. 

Despite its advantages, the electronic lottery scheme suffers from the drawback that the 
user and the merchant must interact for each micropayment, in order to determine whether a 
particular micropayment should be selected for deposit. This requirement considerably slows 
down the electronic payment system, and in some cases renders the scheme impracticable. 

For the foregoing reasons, there is a need for a non-interactive micropayment method and 
system, which allow global aggregation of micropayments to minimize bank processing costs, 
but which at the same time do not require user-merchant interaction in the micropayment 
selection process. 

la addition, it is desirable to incorporate time constraints into a micropayment system. 
For example, it would be advantageous to include in a micropayment system time constraints 
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that require the merchant to deposit any payable check (i.e. a micropayment that is properly 
selected for deposit) in the bank within a reasonable time period, in order to receive payment 
jBrom the bank. In this way, the user would not be charged too late, i.e. when a possible 
expenditure for the transaction is no longer in his budget This type of constraint would also give 
an extra incentive to the merchant to verify that the time information on a check C is accurate, 
thereby enhancing the security of the system. 

Another problem inherent in probabilistic micropayment schemes, besides the 
inefficiency caused by user-merchant interaction in the selection process, is the risk to the user of 
being charged in excess of what he actually spends. A user in a probabilistic micropayment 
scheme must deal with the probability (albeit small) that in some cases, by bad luck, he may 
have to pay more than what he actually spent. Such occurrences may be rare, and the relative 
impact of such a rare occurrence may decrease dramatically with the number of micropayments 
made. Nonetheless, the possibility, however slim, of being excessively charged may constitute a 

strong obstacle to a widespread acceptance of the scheme. This is because ordinary users are 

generally not accustomed to managing risk. 

For the foregoing reasons, there is a need for a micropayment method and system, which 

not only minimizes bank processing costs, but also guarantee that the user is never charged in 

excess of what he actually spends. 

Finally, micropayment systems which attempt to increase their efficiency generally call 

the bank into action only with respect to those payments that have been selected for payment by 

the merchant, and that generally constitute only a small fraction of the total number of payments. 

Such micropayment systems, however, do not provide the bank with any flexibility or control 

over the payment selection process. Such control may be advantageous to the bank in managing 

its risk. 

It is therefore desirable that a micropayment scheme be available which not only 
eliminates the need for user-merchant interaction in the selection process, and shifts the risk of 
excessive payment away from the user to the bank or the merchant, but also provides the bank 
with some flexibility and control over the payment selection process. 

Summary of the Invention 
The present invention relates to probabilistic micropayment schemes, which allow a user 
U (or other payor, henceforth referred to as "U" or "user") to estabhsh payment to a merchant (or 
other payee, henceforth referred to as "M" or "merchant") for at least one transaction T. 
Typically, T has a very low value Tv. although the scheme featured in the present invention is 
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applicable to any value of Tv. The micropayment schemes featured in the present invention 
minimizes the costs necessary for processing such micropayments, thereby significantly 
increasing the efficiency of the system. A number of additional advantages are also offered, as 
described below. 

In a first embodiment of tiie invmtion, a micropayment protocol is presented which 
allows the merchant to determine, immediately upon receipt of a check and without interacting 
with the user, whether or not the check should be selected for payment. Unlike prior art 
probabilistic micropayment schemes, the micropayment protocol in this embodiment does not 
require that the payability determination be deferred until an interactive selection protocol takes 
place between the merchant and the user. 

In a second embodiment of the invention, the micropayment scheme of the present 
invention incorporates time constraints into the system and uses them in a special way. These 
time constraints require that information regarding the time and/or date of the transaction be 
provided on a check, and that the time information on the check satisfy predetermined criteria, in 
order for the check to be selected for payment. 

In a third embodiment of the invention, a selective deposit protocol is presented, which 
eliminates any risk to the user of being charged in excess of what he actually spends. 

Finally, a fourth embodiment of the invention features a deferred selection protocol, 
which provides the bank (or other third party or broker, henceforth referred to as "bank") control 
and flexibihty over the payment process. 

In a micropayment scheme in accordance with the first embodiment of the present 
invention, a user U uses the records relating to the transaction T, in order to create a data string C 
related to T. C may be an electronic check signed by creating a digital signature for T, using a 
secretkey of theuser. The user causes the merchant to receive the check C. Upon receipt of C, 
the merchant associates with C an item V that is substantially unpredictable by the user. The 
merchant may use secret information SI, known only to the merchant, in order to associate V 
with C. By way of example, V may be the merchant's digital signature for C, denoted by 
SIGm(C), and created by the merchant using the merchant's secret signing key in a pubUc key 
digital signature scherqe. 

The merchant then determines whether V satisfies a property P. In a preferred form, the 
property P may be related to the probability s that a given check C be selected for payment 
(0<s<l). If the merchant determines that the item V derived firom the electronic check C does 
not satisfy the property P, the merchant simply discards the check C, and the bank never sees the 
check C. If the merchant determines that the item V (for example, SIGm(C)) does satisfy the 



7 



wo 02/088874 PCT/US02/12189 
property P, the merchant causes the bank to receive information I that enables the bank to also 
verify whether V satisfies P. For example, I may be (or may include) the merchant's public key 
for the merchant's digital signature scheme, corresponding to the merchant's secret key used to 
create V. Upon receipt of I, the bank undertakes to independently verify whether V satisfies the 
property P. If the bank verifies that V does indeed satisfy the property P, the bank causes the 
merchant, or a fourth party other than the merchant, flie user, or the bank, to receive an amount 
of money A. The amount A is typically greater than Tv, and in one form, may be related to the 
product of Tv and the multiplicative inverse of the probabihty s. The amount A may be given by 
A = [Tv*l/s]. 

A system for establishing payment for a transaction T, in accordance with the first 
embodiment of the present invention, includes a communications chamiel for transmittmg 
electronic data between a first party (user or other party), a second party (merchant or otiier 
party), a third party (bank or other party), and a fourth party. The system includes means 
operative by the first party for inputting and storing a data string C derived from T. The system 
fiarflier includes means operative by the second party and responsive to C, for mputting and 
storing an item V associated with at least a portion of C and substantially unpredictable by the 
first party. The system includes means operative by the second party, for determining whether V 
satisfies a property P. The system further includes means, selectively operative by the second 
party when V satisfies P, for causing a third party to receive information I enabling the third 
party to verify that V satisfies P. The system fiarther includes means, selectively operative by the 
third party when V satisfies P, for causing a fourth party to receive an amount A. 

In a second embodiment of the present invention, time constraints are incorporated mto 
the non-interactive micropayment protocol described above. In this embodiment, a user can 
estabUsh payment to a merchant for a transaction T that is characterized in part by a time t. 
Typically, the time t indicates the time and/or date at which the transaction T takes place. The 
user creates a data string C that is related to T^ In this embodiment, C must contain information 
regarding the time t of T. The user causes the merchant to receive C, or at least a portion of C 
that includes information on t. The merchant associates with C (or with the portion of C that he 
received) an item V that is substantially unpredictable by the user. The item V is a function of 
the time information on C, for example the merchant's digital signature (created using the 
merchant's secret key) of at least a portion of C that includes tiie time infonnation. V may also 
be a digital signature of G(C), where G(C) denotes a fimction of C, or an algorithm using C. For 
racample, G(C) may be a function that returns time/date information of C (e.g, the exactly same 
time/date information of C, or that time/date information "rounded up"), or time/date information 
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of the transaction T to which C refers. The merchant then determines whether V satisties a 

property P. If V does satisfy P, the merchant at time t' causes the bank to receive information I 

(which may include for example the merchant's public key corresponding to the merchant's 

secret key used to create V) enabling the bank to verify whether V satisfies P. 

In the second embodiment of the invention, in order for the bank to cause a foxarth party 

to receive an amount A, t' - 1 must be less than a predetermined time iaterval. This is another 

requirement, in addition to the requirement that V satisfy P. In other words, the bank will credit 

the merchant's account only if the merchant presents a payable check that contains information 

regarding a time t (at which the transaction T occurred), which is within prescribed time limits. 

For example, if the transaction T occurred on a day i, then the merchant may be required to 

deposit the corresponding check C within the end of the day i, or by day i+1, or by day i+n, 

where n is a predetermined integer. The time constraints in the protocol thus requires a timely 

deposit. Requiring timely deposits provides benefits by ensuring that the user is not charged too 

late; it also allows the bank to control other forms of risk, such as those arising from back-dated 

checks. 

In a third embodiment of the present invention, a selective deposit protocol is presented 
which guarantees that a user is never charged more than what he actually spends. For each of 
one or more transactions Ti (i = 1, . . . , n), the user derives a check/micropayment Ci having a 
face value TVi (possibly worth only a firaction of the costs necessary for the bank to process a 
transaction such as Ti), according to an imderlying probabilistic payment scheme. 

In the third embodiment of the invention, each check Ci includes a progressive serial 
number Si, preferably starting fi-om 1 . The serial number S\ is preferably representative of the 
position of the check Ci relative to other checks, in a time-ordered succession of checks derived 
by the user. In the third embodiment, the aggregate debit amoimt for a user is guaranteed to 
never be greater than the aggregate amoimt actually spent by the user, denoted by TVagg for 
convenience. Typically, when the user writes his i-th check, the aggregate amount TVagg is 
given by the aggregate amount of his checks, namely: 

TVagg = TVi+TV2+...+TVi. 

For instance, the micropayment scheme featured in the third embodiment of the present 
invention forces Di to be no greater than TVagg = TVi+TV2+...+TVi, if Ci is the first check that is 
found to be payable, and Di is the corresponding debit amoimt. This guarantee is accomplished 
through a protocol in which the bank keeps track of the serial numbers of the checks it receives 
firom the merchant. Before debiting the user, the bank must determine the serial number Smax on 
the last check, among the ordered succession of checks, upon which payment was made. In an 
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illustrative case, all of the transactions axe worth an equal value TV. In this case, if Q is the 
next payable check, then the bank caiises the user to be debited by an amount Di = (Si - Srmx) * 
TV. The amount Di thus only depends only on the number of checks the user has written since 
the last payment was made, and the aggregate debit amount is guaranteed to be no greater than Si 
*TV. 

Finally, in a fourth embodiment of the present invention, a deferred selection protocol is 
presented, which provides the bank with greater control and flexibility over the payment process. 
As in previous embodiments of the invention, the user derives a data string or "check" Q for 
each of one or more transactions Ti (i = 1, . . , , n), each having a value TVi, and causes the 
merchant to receive Q. 

In the fourth embodiment of the invention, the merchant imiquely associates groups of 
the checks Cj that he has received into m lists L^, where k = 1, . . . , m. Each list includes data 
strings C^i, . . . , C^na, where represents the total number of checks in a given list L^. Thus, if n 
is tiie total number of checks in all m lists, H^i^i /k = n . 

The merchant conmiits to the m lists (k = 1, . . . , m), by computing a commitment 
CM^ for each L^. The commitment CM^ is preferably a hash value H(L^), where H is a one-way 
hash function. The merchant causes the bank to receive the commitments CM^ (k = 1, . . . , m). 

Upon receipt of CM^ (k = 1, , . . , m), the bank implements the deferred selection protocol 
featured in the fourth embodiment of the present invention, by selecting one or more integer 
indices ii, iz, . - . ir. The value of r is arbitrary, and up to the bank. The bank causes the merchant 
to receive the selected indices ii, i2, . . . ir- 

In response to receipt of the selected indices ii, i2, . . . ir, ttie merchant de-commits CM^\ 
cm". . . CM*", thei-eby revealing V\ , . L^' to the third party (e.g., a bank). A fifth party (which 
may be the bank, or an entity other than the bank) causes a fourth party (which may be tiie 
merchant, or an entity other than the merchant) to receive a credit amount CR. The fifth party 
causes the user to be debited by a debit amount D. 

Preferably, the credit amount CR is related to V^, where V*" represents the aggregate 
value of all the checks contained in a given list L*^, i.e. 

V^ = TV\ + . . . + TV*'/k. 
The credit amount CR may be given by the aggregate value of all the checks contained in all of 
the m lists, i.e. 

CR = V' + ... + V^4-...V""= I,\^iY\ 
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In this case, commitments to the values V may have been provided to the bank when the 
commitments CM^ to the Usts were provided; then all the values V are deconraiitted after the 
bank selects some of the hsts by specifymg their indices. 

Alternatively, the credit amoimt CR may be related to the aggregate value of all the 
checks contained in just those lists whose indices were selected by the bank. This credit amount 
CR may be related to the just-mentioned aggregate value by a scale factor such as m/r (where the 
integers m and r are referenced above), in order to reflect the fact that the bank is only seeing a 
fraction r/m of the checks. 

The corresponding debit amount D may be derived in one of several ways; the choice of 
method for deriving D may or may not be related to the method for computing CR. For example, 
the value D may be related to the aggregate value 

+ -I- , . . + V', 

of all the checks contained in those lists whose indices match the indices selected by the bank 
and forwarded to the merchant; for example it might be the value of this sum scaled by a factor 
such as m/r. Or, the value D might be derived from the credit amoxmt CR; for example, it could 
be equal to the credit amount CR. Or, the value D could be derived from the serial numbers on 
the checks contained in the selected lists, in the manner previously described. In most 
applications there will be a number of distinct users, and the amount each user is charged wUl 
depend in one way or another on just those checks written by that user in tlie selected lists. A 
preferred method of computing the debit amount Du for each user U would be to use a method 
based on the serial numbers of the checks written by user U. 

Brief Description of the Drawings 

The invention can be more fully understood by referring to the following detailed 
description taken in conjunction with the accompanying drawings, in which: 

Figure 1 provides, in schematic flow-chart form, an overview of a method for 
micropayment transactions, in accordance with a jSrst embodiment of the present invention. 

Figure 2 provides a schematic block diagram illustrating the components of a 
micropayment system for establishing payment for a transaction, in accordance with the first 
embodiment of the present invention. 

Figure 3 provides, in flow-chart form, an overview of a method for micropayment 
transactions in accordance with a second embodiment of the present invention 

Figure 4 provides, in flow-chart form, an overview of a method for micropayment 
transactions in accordance with a third embodiment of the present invention, which includes a 
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selective deposit protocol that eliminates the risk to the user of being charged in excess of what 
he actually spent. 

Figure 5 provides a schematic block diagracn illustrating the components of a 
micropayment system for estabUshing payment for a transaction, in accordance with the third 
embodiment of the present invention. 

Figure 6 provides, in flow-chart form, an overview of a method for micropayment 
transactions in accordance with a fourth embodiment of the present invention. 

Figure 7 provides a schematic block diagram illustrating the components of a 
micropayment system for establishing payment for a transaction, in accordance with the fourth 
embodiment of the present invention. 

Detailed Description 

hi the present invention, methods and systems are presented, which mcrease the 
efficiency and flexibility of micropayment schemes. 

In the present invention, a micropayment system involves at least a first party, a second 
party, and a third party. In one form of the invention, the first party may represent a payor, for 
example a buyer or a user. The second party may represent a payee, for example a merchant of 
goodsor a vendor of services. The third party may represent a broker or a bank. Additional 
parties may also be involved. In some situations, a single entity may play the roles of more than 
one party: forinstance, the roles of both the second party and the third party. An example 
would be the situation in which a user wishes to make micropayments to his own bank. 
Altematively, a single entity may play the roles of both the second party and the fourth party. 

For ease of reference, in the sequel we may use the term "user" to refer to the "first 
party", the term "merchant" to refer to the "second party" and the term "bank" to refer to the third 
party broker, respectively. It is to be understood, however, that the first party need not be a user, 
nor the second party a merchant, nor the third party a broker or a bank 

Finally, additional parties may also be involved in micropayment schemes in accordance 
with the present invention. For instance, the third party may cause a fourth party (possibly 
cooperating with the second party) to receive payment. For example the first party may be the 
paying device of a motorist passing through a toll booth, the second party a device at the toll 
booth, the third party the motorist's bank, and the fourth party an entity collecting tolls, hi this 
case, the motorist may present a micropayment at the toll booth device, and if the proper 
conditions arise a payment may be made by the motorist's bank to the toll-collecting entity. As 
another example, a fifth party may be involved: the third party may cause the fifth party to make 
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an actual payment to the fourth or second party. For example, elaborating on the previous 
example, the third party could be the manufacturer of or an entity controlling or renting the 
paying device, and the fifth party may be the motorist's bank, which may ultimately pay the 
fourth party. The same fifth party, or the third party or another sixth party, may actually debit 
the first party or another party on his behalf 
I. Non-Interactive Micropavment Scheme 

In a first embodiment of the invention, a micropayment scheme is presented which 
eliminates the need for a merchant to interact with the user, in order to determine whether or not 
a given payment should be selected. In this embodiment, when a user wishes to make a 
payment, the user creates an electronic document or "check," and causes the merchant to receive 
the check. In this embodiment, the merchant can determine, immediately upon receipt of the 
check, whether or not the check should be selected for presentation to the bank, so that an 
appropriate debiting of the user's account and a crediting of merchant's accoimt can occur. The 
merchant is able to make such a determination without interacting with the user. Unlike in the 
case of prior art electronic lottery micropayment schemes, there is no need to defer such a 
detemiination until an interactive selection protocol takes place between the user and the 
merchant. In Ms way, the efficiency of the micropayment process is significantly enhanced. 

In the first embodiment of the invention, the user typically needs to pay the merchant 
because of a transaction T, or a series of such transactions T. The transaction is typically 
characterized by a transaction value Ty which may be very low, for example one cent or a 
fraction of a cent. The bank would therefore incur processing costs much higher than the 
transaction value itself, if the bank were to process payments for every single transaction. 

Figure 1 provides, in schematic flow-chart form, an overview of a method for 
micropayment transactions, in accordance with the first embodiment of the present invention. 
When a user wishes to make a payment in a micropayment scheme in accordance with the 
present invention, the user creates a data string or "electronic check" C, and sends C to the 
merchant, or otherwise causes the merchant to receive C. The check C is typically derived from 
a record T of the transaction. For example, the check C may be generated by creating a digital 
signature for the transaction, SIGu(T), using a secret key of the user; this signature by the user is 
verified by the merchant. The user's signature SIGu(T) may include, or may be accompanied by, 
sufficient information about T to enable this verification to proceed. The user may also cause tiie 
merchant to receive, or may incorporate in C, the digital certificate enabling verification of his 
digital signature -e.g., the digital certificate specifying the public key of U to be used to verify 
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U's digital signature. Each check C may have a probabihty or selection rate s (0 < s < 1) of 
beiag selected for payment. 

The merchant associates with the check C an item V that is substantially unpredictable by 
the user, for example a digital signature for C, created using a secret key of the merchant. The 
merchant then determines whether V satisfies a certain property P. In a preferred embodiment of 
the invention, the probabihty that V satisfies P is equal to the selection rate s. If merchant finds 
that V does indeed satisfy P, the merchant causes the bank to receive the information I that 
enables the bank to also verify whether V satisfy P. Otherwise, the merchant discards the check 
C. Upon receipt of I, the bank may verify the user's signature on the check C, if present, and 
discard the check if the signature does not verify. The bank may perform other tests, for 
example those relating to the status of the user's accoimt at the bank, such as determining if the 
account is still in good standing (e.g., whether the relevant user's digital certificate has been 
revoked); the bank may choose not to honor a check if such tests are not passed. The bank then 
verifies that V does indeed satisfy P, and caxises the merchant to receive a sum of money only if 
V satisfies P. 

Referring now in more detail to each element of the micropayment scheme featured in the 
present invention, the "transaction" that causes the payment in the present invention covers a 
broad range of possible situations in which a user may have to pay a merchant. For example, the 
user may pay the merchant in order to purchase services, or information, or physical goods. 
Alternatively, the user may just be paying the merchant without making any purchases, for 
example in order to make a donation to the merchant. Examples of typical transactions T 
include, but are not limited to, the user visiting an informational website, web page by web page 
(each visited web page representing a single transaction T), or audio/video material being 
streamed to the user, minute by minute (each minute of streamed audio/video material 
representing a single transaction T). 

The record T of the transaction may be a data string that includes the descriptive details 
of the transaction. For example, the record T may specify one or more of the following: the 
amount being paid; the description of the goods to be purchased, if any; the identities of the user 
and/or the merchant; the public keys of the user and/or merchant; digital certificates for the user 
and/or merchant; the date and time of the transaction; the identification of any relevant third 
parties, such as the bank or the financial services provider, and any additional information 
needed to identify the user's account. The transaction will hereinafter be referred to in terms of 
the record T that represents the transaction, namely the phrase "the transaction T" will be used to 
refer to the record T that represents the transaction. 
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The data string C derived by the user typically represents an electronic check (sometimes 
also called a payment order), which includes a commitment by the user to pay a given amount 
for the transaction. Typically, the nominal face value of the check C is the transaction value Tv 
for the transaction T. Other information may also be included in the check C. For example, C 
may include the transaction T, or at least a portion of the transaction T, or an indication of the 
transaction T. In a preferred embodiment of the invention, the data string or electronic check C, 
or at least a portion of C, is authenticated. Authentication may be obtained by a variety of 
methods, as known in the prior art. For example, the check C may be authenticated via a digital 
signature, or via a message authentication code, or by virtue of being sent within an 
authenticated session. The check C may be authenticated by a party other than the user, for 
example upon request of the user, or on behalf the user. This method of authentication would be 
particularly useful in the context in which the user wishes to make an anonymous purchase. Any 
other authentication scheme known in the art is also within the scope of this invention. 

The user may use secret information, known to user but not known to the merchant, when 
creating the check C. Typically, for someone who does not kuow this secret information, it is 
computationally infeasible to create the check C. In a preferred embodiment of the invention, 
the process of creating the check C involves the creation of a digital signature by the user in a 
public key digital signature system, and the secret information used by user to create C is his 
secret signing key in this system. In this embodiment, the data string C includes the user's digital 
signature of the transaction T in this system, conveniently denoted as SIGu(T). SIGu(T) is 
created by user using the user's secret key. The user may use any one of the digital signature 
schemes known in the art, in order to create his digital signature. In particular, the user's digital 
signature schemes may include, but are not limited to the following: a deterministic signature 
scheme; a randomized signature scheme; an identity-based signature scheme, as proposed by 
Shamir; an on-line signature scheme; an off-line signature scheme; and a designated verifier 
scheme. The string C may also include other information, such as information about the 
transaction T. 

Having created the electronic check C, the user causes the merchant to receive C. There 
are a variety of ways in which the user may cause the merchant to receive C. The user may 
simply send the check C to the merchant. Alternatively, the user may ask another party to send 
the check C to the merchant. The user may cause the merchant to receive or access the check C 
in different portions, at distinct times. For instance, the user may cause the merchant to receive 
or access the user's public key at an earUer time, before any transaction T takes place. The user 
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may then cause the merchant to receive or access the user's digital signature of C, or a portion of 
C, or a quantity related to T (or a portion thereof) at a later time. 

The merchant may determine whether or not a check C is acceptable, i.e. whether or not 
the check C is in fact signed by user, and whether or not the contents of the check C are 
unadulterated and integral. To accomplish this, the merchant may review public verification 
information that is specific to the user who created the check C. This user-specific public 
verification information may be, for example, the user's public key that corresponds to the secret 
key that the user used in order to create C, or more generally a digital certificate proving that the 
user is authorized to make micropayments, and thus that his micropayments will be honored. The 
same digital certificate can be used for both purposes, that is indicate that the user is authorized 
to make micropayments and that a given public key should be used to verify his digital signature 
in a micropayment check. The merchant may use the user's public key, in order to verify that the 
digital signature on the check C is authentic, i.e. indeed created by user. If the user utilized an 
identity-based digital signature scheme, the public verification information may include a 
specification of the user's identity. Such user-specific public verification information may be 
obtained by the merchant directly from the user. Altemately, such public verification 
information may be obtained by the merchant from a digital certificate, or from publicly 
available information regarding the user (for example a published directory of public keys), or 
from information transmitted by the user in association with the check C or as part of the check 
C. The "user-specific public verification information" need not be available to the general 
public; it need only be available to the merchant(s) and the bank. 

The merchant may take steps to check the authenticity of the user-specific public 
verification information that he obtained. These steps may include, but are not limited to: 
verifying digital signatures or otiber authentication information concerning the user-specific 
public verification information; verifying the signature on a digital certificate; checking the 
expiration date of a digital certificate; and determining whether a digital certificate has been 
revoked. The merchant may also confirm fcom the digital certificate that the user is indeed 
authorized to write the electronic check C; this may involve, for example, further checks on the 
amount, account number, serial number or other information in the check C. 

The merchant associates with every check C that he receives an item V that is 
substantially impredictable by the user. For example, the item V may be substantially 
unpredictable by the user because it would not be computationally feasible for the user to derive 
V from C, i.e., the user would need to perform an impractical amount of computation, in order to 
derive the value of the item V. In one embodiment of the invention, the item V can only be 
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feasibly derived from C using secret infoiination SI known to the merchant, but not known to the 
user. In one embodiment, the secret infonnation SI may be merchant*s secret key in a pubHc key 
digital signature scheme. 

In one form, the item V associated with C by the merchant may be the merchant's digital 
signature for C, denoted by SIGm(C) for convenience, and created by the merchant using a secret 
key of the merchant in a public key digital signature scheme. The digital signature scheme used 
by merchant does not necessarily have to be the same as the signature scheme used by the user to 
create C, and is Ukely to be a signature scheme that is different from the user's signature scheme. 
In this situation, if C is equal to, or includes, SIGu(T), then the item V maybe given by: V = 
SIGm(C). Accordingly, SIGm(C) is a quantity unpredictable to the user, because the user can 
never know the merchant's secret signing key. Therefore, even if the user may control the check 
C in any way he wants, for example by choosing a particular transaction T, SIGm(C) will 
essentially be "random', as far as the user is concerned. In another form of the invention, V may 
be a MAC (message authentication code) value, computed by the merchant using a secret MAC 
key; this MAC key may be known to the merchant and the bank but not to the user. In some 
forms of the invention, the merchant's signature of C may be construed to include the merchant's 
signature or MAC of only a portion of C (such as the date or time in C, a random string included 
in C, or the serial number contained in C), or of a quantity related to C. 

The step of computing the item V need not necessarily follow in time the step of 
receiving C from the user. For instance, the item V may be the merchant's digital signature of 
the date information relating to the transaction T. The merchant may already have computed this 
digital signature before receiving C. 

In the present embodiment, the merchant uses a selection procedure to determine which 
of the checks it has received should be "selected" for payment. The merchant transmits only the 
"selected" checks to the bank, and does not transmit any imselected checks to the bank. It is not 
computationally feasible for the user to determine, at the time the user creates a check, whether 
or not the check will be selected by the merchant or not. In fact, the user may or may not even 
be aware that the merchant uses a selection process and transmits only a fraction of the user's 
checks to the bank, although it may be more likely than not that the user eventually learns about- 
such a selection procedure. 

As part of the selection procedure, the merchant determines whether tlie item V 
associated with C satisfies a property P. In a preferred embodiment of the invention, the 
determination as to whether or not a check C is selected for payment hinges upon whether or not 
V satisfies P. 
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In a preferred form, the selection procedure used by the merchant is such that it is 
possible to estimate, for each selected check, its selection rate or "probability" of being selected 
for payment. In particular, the selection procedure may be one that is estimated to select a fixed 
fraction of all the checks. In this case, the property P may be related to a constant s, where 
0<s<l, and where s is the probability that a given micropayment be selected for actual payment, 
and where this probability s is fixed and known. Alternatively, V may satisfy P with a 
probability that can be determined fi-om the data string C or from a portion thereof, or from the 
record T or portion thereof, .or from a combiuation of the data string C and the record T. In other 
words, the fraction of checks that are selected may depend upon parameters supplied by the user 
in the check C. For example, it may depend on the amount of the check. Altematively, the value 
s maybe specified within the user's digital certificate that binds the user's public key to the user. 
Altematively, the property P may be guaranteed to hold for a constant fraction of the values of 
the item V. Altematively, the property P may be guaranteed to hold for a certain fraction F of V, 
where the fraction F may be determined from the data string C, from the record T, from portions 
of C and T, or from a combination of C and T. Altematively, the merchant may obtain 
information from the bank that can be used to determine s and/or the property P. 

The property P may be specified beforehand, i.e. before the transaction T occurs and a 
check C is derived fi-om T. An example of such a property? would be: "the last ten bits of V 
corresponds to a number less than x, where x is a constant number." Altematively, the property 
P may be specified within, or obtainable from, the transaction T, or the check C, or a 
combination thereof. An example of such a property P would be: "the last 10 bits of V 
corresponds to a number less than the number corresponding to the last ten bits of C." The way 
in which the selection rate s is determined may involve a combination of the above approaches, 
or variations thereof that would be obvious to one skilled in the art. 

In one form, the merchant may use the secret information SI known only to the merchant, 
in order to determine whether V satisfies P. Such secret information SI may include, for 
example, the merchant's secret key in a public-key digital signature scheme, or the merchant's 
secret key in a public-key cryptosystem, or the merchant's secret key in a public-key digital 
encryption scheme. Preferably, the merchant's digital signature algorithm should be 
deterministic. 

In one embodiment of the invention, the property P may take the following form: 
F(V)=F(SIGm(C))<s, (1) 
where FQ represents a public fimction that takes an arbitrary bit string as an input, and returns as 
output a number between 0 and 1, and s is a constant greater than 0 and less than 1 and 
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represents (or at least determines) the selection rate for the micropayment scheme, i.e. the 
probability that a given check C be selected for payment. As one example, F might operate on a 
binary input string V by pre-pending a zero and a point, and interpreting the result as a binary 
number. In this example, if V were the input string "01 1," F would operate on V to yield 
"0.01 1," which would be interpreted as the decimal jfraction 3/8. Since SIGm(C) is essentially a 
random (impredictable) number, as explained above, then F(SIGm(C)) is also a random and long 
enough number between 0 and 1. Therefore, F(SIGm(C)) would be less than the rate s, and 
therefore the property P satisfied, essentially for a firaction s of all the checks C which the user 
causes the merchant to receive. In another embodiment, the function F would first apply a hash 
fimction or other deterministic fimction to its input, and then proceed as before by pre-pending a 
zero and point, and interpreting the result as a binary number, hi another embodiment, the 
property P may take the following form: 

F(V)=F(SIGm(G(C)))<s, (r) 
where GQ represents a function that is applied to the check to produce a data string. For 
instance, the function G may just return the serial number of the check C. 

It should be emphasized that the merchant need not interact with the user, in order to 
determine whether a check should be selected for payment. In a case in which the property P is 
determined according to equation (1), it is easily seen that merchant can immediately verify 
whether a check C is payable: the merchant can easily evaluate F(SIGm(C)) using his own secret 
signing key, and compare F(SIGm(C)) to the selection rate s. It is crucial that F(SIGm(C)) be 
substantially unpredictable to the user; it should also be a number of sufficient precision. For a 
selection rate that is practically reasonable, for example 1/128 or 1/1024, it would be sufficient 
for SIGm(C) and F(SIGm(C)) to be 10-bits long. A typical digital signature is, instead, hundreds 
of bits long, and therefore represents an overkill. 

In this embodiment of the invention, the merchant causes the bank to access information 
I, which enables the bank to also verify whether V satisfies P, once the merchant himself has 
detenrdned that the item V (for example SIGm(C)) does satisfy the property P. In an exemplary 
embodiment of the invention, the information I may include the merchant's public key 
corresponding to the secret key that was used to create SIGm(C), or the merchant's certificate for 
that pubUc key. The information I may also include the merchant's digital signature of C, 
namely V or SIGm(C), The merchant may cause part of the information I to be accessed by the 
baiik before check C is even generated. For instance, the merchant may have given the bank in 
the past its own certificate, and the bank may have stored it. If the merchant determines that the 
item V derived firom the electronic check C does not satisfy the property P, the merchant simply 
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discards the check C. The bank never sees the check C. However, if the check were properly 
made, even though not selected for payment, the merchant would still normally provide the user 
with the goods/services that the check intended to buy. Only those checks C for which V 
(associated with C) satisfies the property P are selected for payment by the merchant, and 

) forwarded to the bank. The bank is thus called into action only for a fraction of the 
micropayments made by user. 

Because the bank is only seeing a fraction s of the checks created by the user and 
received by the merchant, an adjustment in the pa>ment amounts needs to be made to account for 
(at least approximately) the value of the "missing" (unselected) checks. In one approach to 

) maldng such an adjustment, each check forwarded to the bank for deposit results in a 
"macropayment" that has a value of 1/s times the nominal face value Tv of the check C. 
Wlien s is variable, the applicable s is the s related to the procedure used to select C. For 
example, if s were 1/1000, and the transaction value Ty were 1 cent, then on the average, only 1 
out of 1000 micropayments would be selected for payment, and 999 out of 1000 micropayments 

5 would be discarded. A payment of 1000 cents, or $10, would be made for the selected 

micropayment. In this way, only a single processing cost would be iDCurred for each 1000 
micropayments, on the average, resulting in a large savings in processing cost. 

The bank verifies, for each check C received from the merchant, whether the check C 
should indeed have been selected for payment, using information I such as merchant' public key 

d in merchant's digital signature scheme. In other words, for each check C received from the 
merchant, the bank also verifies whether V satisfy the property P, using information I. If the 
bank verifies that V does indeed satisfy the property P, the bank causes the merchant, or a 
designated fourth party other than the merchant, the user, or the bank, to receive a sum of money 
corresponding to the value of the macropayment. The bank typically causes the payment to be 

5 made out of the user's account, and into the merchant's account or into some designated fourth 
party's account. 

The bank at its discretion and/or according to its policies, may refuse to pay for a check 
under certain circumstances, such as when the user's account is in arrears, when the user's 
certificate is revoked, or when the merchant or user is suspected of attempted fraud of some sort. 
0 For example, the bank may take steps to ensure that if a merchant submits the same check twice, 
then payment is made at most once. The bank may refuse to pay for a check that has been 
previously processed. The bank may also choose to hold a check for payment until the user has 
deposited sufficient funds in his account to cover the check. 
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The micropayment scheme featured in the first embodiment of the present invention may 
involve four parties, a first party, a second party, a third party, and a fourth party, where all four 
parties are totally distinct. As an example, the first party may be a user going through a 
toUbooth, the second party may be a device at the tollbooth, the third party may be the user's 
bank, and the fourth party may be the highway owner. Alternatively, the first party may be a 
user downloading a song, tlie second party may be a provider of the song, the third party may be 
the user's bank, and the fourth party may be a music distributor. Alternatively, the third party 
may be the first party (i.e. user)*s bank, and the fourth party may be the second party (i.e. 
merchant)'s bank. In this case, the second party would be causing the user's bank to make the 
payment to the second party's bank, for the second party's benefit. Additional parties, other than 
the first, second, third, and fourth parties, may also be involved in the micropayment scheme of 
the present invention. For example, the first party (user) may send a check C to a second party, 
which is a device that forwards the item V (if the property P holds for V) to a third party which is 
the user's bank. The user's bank (third party) pays the fourth party, which is the beneficiary's 
bank, for the benefit of the beneficiary, who is a fifth party. 

The amount of the payment may depend on both the nominal face value (Tv) of the check 
and the estimated probability s that such a check would be selected for payment. The amount of 
the payment out of the user's account, and into the merchant's accoimt, may be given by the 
nominal face value of the check, multiplied by the multiplicative inverse (1/s) of the estimated 
probabiUty s that such a check would be selected, adjusted by any applicable bank processing fee 
that the bank may charge the user and liie merchant, respectively. 

As mentioned before, a micropayment scheme is very useful for enabling purchases of 
low-value items, for example a web article or a web page. In the prior art, subscription methods 
have been widely used, in order to enable users to purchase low-value items. For instance, by 
subscribing to a web service, the user essentially aggregates many fiiture low-value transactions 
into a single macropayment. This practice, however, may not be optimal for the user, because 
the price of a subscription could be more than the user is willing to pay, if the user is currently 
interested in a specific item but is not sure that he will want or need to access future items. As a 
result, the vendor may lose some business, because the user may decide against buying a 
subscription (i.e. making a macropayment "in advance"), and may renoxmce his desired item. 

A probabilistic micropayment scheme, as featured in the first embodiment of the present 
invention, may be extended in a manner that bridges subscriptions and individual sales, as 
follows. A merchant may offer users two options: 1) a subscription that enables the users to 
obtain many items within a given time interval (e.g., the subscription may offer a buyer the 
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access to all web pages of the merchaat, for one year), and 2) individual items a la carte. The 
user may decide to buy an individual item silone, according to its declared price, Ty. The user 
would pay the merchant with a probabilistic check having a face value of Ty, and the merchant 
would provide the user with the desired item. If the probabilistic check should be selected, 
however, the check will actually cause the merchaat to receive a much higher monetary value, 
for instance A = Ty* 1/s, where s=l/1000, in the case where the probability that an individual 
check be selected for payment is 1/1000. The amount A, received by merchant, would exceed 
the cost of the merchant's subscription service. In this case, the user would be rewarded by 
obtaining a subscription for jfree. If the cost of a subscription is higher than A, the user may be 
rewarded by obtaining A as a credit towards the cost of purchasing a subscription from the 
merchant. 

The above-described method for bridging subscriptions and individual sales offers 
several additional incentives to the user. Assume, for simplicity only, that all items have the 
same cost (e.g., one cent), that a subscription costs $10 and that the probabilistic check has a face 
value of one cent but upon selection for payment, actually ends up costing the user $10, because 
the probability for selection in the imderlying scheme is 1/1000. Then, the user will see that, on 
average, only 1 out of 1000 of his checks becomes payable, and that, when he actually pays $10, 
he also gets a subscription for free. Therefore, in some sense the usee never has to decide 
whether he should purchase a subscription, or whether he should opt for i la carte items: the 
user may always go a la carte, because he would always end up, either with obtaining an item for 
free, or pay for the item, but have a subscription thrown in for free, in retum. In this way, even if 
the user is hit with a $ 10 payment long before making 1000 1-cent purchases, the micropayment 
scheme would always appear fair and attractive to the user. The process would also look 
attractive to the merchant, since he may otherwise lose customers that would not consider buy a 
subscription anyway. The merchant can also adjust the per-value Ty upward a bit to include a 
pro-rated cost of a subscription, if he feels that the user was getting too good of a deal. 

Figure 2 provides a schematic block diagram illustrating the components of a 
micropayment system 100 for establishing payment for a transaction T, in accordance with one 
embodiment of the present invention. The system 100 includes cormnunications means 1 10 that 
permit the user, the merchant, and the bank to transmit electronic data, and even payments, 
among themselves. The electronic data may include data strings that represent electronic checks, 
or strings that represent messages. In one embodiment, the communications means 110 may 
permit access to remote servers. The cormnunications means 110 may include a modem, and 
one or more network interface devices known in the art, including but not limited to network 
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interface cards. The commuoication means 1 10 may include buses, for example address buses 
114 and data buses 115, that permit transfer of data between different network nodes. 

The system 100 also includes a first processing means 105, and a second processing 
means 106. The first and second processing means may be computer systems, for example 
digital computers running a DOS or Windows operating systems, and are connected to the 
address buses 114 and the data buses 115. Each of the processing means 105 and 106 typically 
include storage means 121 for storing data, input means 122 for inputting data, and a Central 
Processing Unit ("CPU") 123 that implements the system commands. The storage means 121 
may include a computer memory, and a data storage device such as hard disks, CD-ROMs, and 
the like. The input means 122 may be any input device knovm in the art, for example a 
coiiventional keyboard. 

The first processing means 105 is operative by a fitst party for deriving, inputting and 
storing a data string C related to the transaction T. The second processing means 106 is 
operative by a second party and responsive to C, for associating an item V with at least a portion 
of C. The second processing means 1 06 is also operative to detennine whether V satisfies a 
property P. For example, a set of instructions can be inputted into the CPU 123 of the second 
processing means 106, to cause the CPU to derive the item V associated with C (or a portion of 
C), and to cause the CPU 123 to determine whether V satisfies a property P. This is a necessary 
condition that must be satisfied, in order for the next step to be executed by the CPU 123, namely 
the ordering of the transfer to a third party (the bank) of information I enabling the third party to 
verify whether V satisfies P. The CPU 123 can be programmed to be selectively operative when 
V satisfies P, to transmit the information I to the third party. 

The system 100 also includes means 140, selectively operative by the third party when V 
satisfies P, for causing a fourth party to receive a sum of money. The means 140 may also be a 
computer system, having a CPU that can be programmed to be selectively operative when V 
satisfies P, to order the transfer of a payment to a foiarth party. 

In summary, the micropayment scheme featured in a first embodiment of the present 
invention minimizes processing costs, while ehminating the need for user-merchant interactions, 
and while allowdng each party to pay or receive approximately ttie correct expected value, over a 
period of time during which a relatively large number of micropayments take place, 
n. Micropayment System Including Time Constraints 

Different variants are possible within the non-interactive fi-amework that is presented in 
the first embodiment described above. In particular, in a second embodiment of the invention, 
time constraints can be incorporated. The micropayment scheme, as described in the previous 
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section, may allow a merchant to deposit a payable check at any time. In many cases, however, 
it is advantageous for the bank to have the capability to refuse to credit the merchant's account 
unless the merchant presents a payable (i.e. properly selected) check whose time information 
indicates that the check is being presented within a predetermined time interval from the time at 
which the relevant transaction occurred. 

In the second embodiment of the invention, a micropayment scheme is presented which 
allows the user to estabUsh payment for a transaction T that is characterized in part by a time t. 
Typically, the time t represents the time and/or date on which the transaction T occurred. Figure 
3 provides, in flow-chart form, an overview of a method for micropayment transactions in 
accordance with a second embodiment of the present invention. The user derives from T a data 
string or electronic check C from the transaction T. In the second embodiment, the check C, or 
the transaction T to which C refers, must contain infonnation IN regarding the time t of the 
transaction T. 

The usCT causes the merchant to receive at least a portion of C that contains IN. The 
merchant, upon receipt of the portion of C, associates with C an item V that is substantially 
unpredictable by the user. In this embodiment of the invention, the substantially unpredictable 
item V is defined in terms of the time t of T. For example, V may be created using the 
merchant's secret key in a public digital signature scheme and may be given by SIGm(C), i.e. the 
merchant's digital signature for C or for the portion of C that includes infonnation on t. In the 
latter case, more precisely V= SIGm(G (C )), where G is a function of C that returns time 
information about C, ' 

The parameter s and functions F and G may also be used in the micropayment scheme to 
determine the property P that V should satisfy. The manner in which s and the function F and G 
are specified, as well as the manner in which the property P is specified, may vary, in ways 
similar to the methods of specifying s, F, and P described in the previous section. For example, 
the check C (or the transaction T to which C refers) may directly specify the property P that 
should be used with the proper value V associated to C. For example, the function F may 
determine the property P, where P is given by: 

F(V) = F(SIGm(C))<s, 

where s is a number between 0 and 1, and represents the probability that a given check C be 
selected for payment in the scheme. 

In the second embodiment of the invention, the merchant's signature may just apply to a 
function G of C, rather than applying to all of C. That is, the property P may be given by 

F(V) = F(SIGm(G(C)))<s. 
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Again, function G may be specified in one of several ways. For example, it may be fixed, or be 
specified by C, or be specified by the corresponding transaction T, or be specified by a certificate 
(e.g., of the merchant or of the user), or be specified in other information provided by the bank. 

A particularly useful function G may be the function that returns the time information IN 
of C. In this way, the item V (substantially unpredictable by the user) is a function primarily of 
the time t of the transaction T, and therefore the property P depends primarily on the time t of the 
transaction T. Notice that the time information extracted by G may be related to but need not to 
coincide with t. For instance, t may specify the day, the hour, and the minute of T, while G may 
return a time indication with a different granularity: e.g., it may specify t itself, but just up to the 
day (or day and hour but not minute), or the next hour after t. In the second embodiment of the 
invention, the value G(C) being signed by the merchant should always be construed to include 
time information. 

After determining that V satisfies P (ia the cases where this is true), and that the check 
passes other tests (for example, whether the user's signature, if present, is valid, the merchant at 
time t* causes the bank to receive some or all of information IN regarding the time t of T. The 
merchant may present to the bank all of C, or at least a portion of the check C that contains IN. 
The merchant also causes the bank to receive information I enabling the bank to independently 
verify that V satisfies P. The merchant may cause the bank to receive part of I before V is even 
computed. After receiving the relevant portion of IN, the bank can determine whether t' (i.e. the 
time at which the merchant presented the check to the bank) is sufficiently close to t. The bank 
may discard the check C if the elapsed time |t' - 1| is greater than a predetermined amount. The 
bank may also refuse or defer payment at its discretion or according to its poUcies if other 
conditions hold, such as when the user's signature on the check C does not verify, or the user's 
accoimt is in arrears, or the user and/or merchant are suspected of firaud, etc. 

Using I, the bank independently verifies that V satisfies P. Only if V indeed satisfies P, 
and all other tests are passed (such as the test that |t* - 1| is less than a predetermined time 
interval) does the bank cause the merchant (or other fourth party) to receive a sum of money. 
The predetermined time interval may be one day, for example, or one week, or even a given 
number of hours. 

As one example, if the transaction T to which a check C refers to happened in day i, then 
the micropayment system may require that the merchant deposit the check by the end of day i, or 
by the end of day i+1, or by the end of day i+n, where n is an integer number indicative of the 
number of days within which it makes business sense for the merchant to deposit. This type of 
requirement gives an extra incentive to the merchant to verify the time accuracy of the checks he 
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receives, which provides an added security benefit to the merchant. 

In one form, if ti represents the time at which the user causes the merchant to receive a 
portion of C including IN, then the merchant may refuse to proceed if the time ti is not within the 
prescribed time constraints. In such a case the merchant could refuse to provide the 
"merchandise" (goods, services, or information, for example) requested. Timely deposit also 
ensures that the user is not charged too late, i.e. when that possible expenditure is no longer in 
the user's budget. 

Referring to G(C) in more detail, G(C) may be the function that returns the date and/or 
time infonnation of C, or of the transaction T to which C refers. For instance, if such a date is 
2001.01.01, then V may consist of SIGm(2001.01.01). This is substantially unpredictable to the 
user, if the merchant has never signed such a date before. In this case, the property P that V must 
satisfy includes comparing SIGm(2001.01.01) or F(SIGm(2001 .01.01)) with C, a portion of C, 
some function of C, or a pre-specified constant. For example, one such property P might be 
formulated as: does a selected m-bit substring of SIGm(2001 .01 .01) match a selected m-bit 
substring of C? 

It should be noted that the above-described method of associating V with C has a number 
of advantages. In particular, the merchant may compute SIGm(2001.01.01) before even 
receiving C firom the user on January 1st, 2001. Therefore, once C has been received that day, 
the merchant may much more quickly verify whether P satisfies the needed property P. For 
instance, if P consists of F(SIGm(2001.01.01)) < s, for some fixed number s, then P depends on 
V alone, and not otherwise on the check. Thus the merchant can determine whether P holds once 
and for all, and evea before January 1st, 2001. If P does hold, then the merchant can forward 
• (without any further verification) all the checks he receives that day to the bank, for payment. If 
P does not hold, he will discard (without any further verification) all the checks he receives that 
day. In this way, the number of signatures that the merchant has to perform is minimized. 

Alternatively, the property P may consist of whether certain m-bits (say, 10-bits) of 
SIGm(2001.01.01) match a given 10-bit string that the user includes in C. In this case, even 
though the property depends on both V and the check C, determining whether P holds is aknost 
immediate. In fact, even though the computation of a digital signature may be rather complex, 
the merchant needs to compute SIGm(2001.01.01) only once on or before January 1st, 2001, and 
then store the signature (or any given m-bits thereof). In this way, the merchant's effort that is 
required per check would only consist of a trivial comparison of two 10-bit strings. This enables 
the merchant to cause the bank to receive all of the information I enabling the bank to 
independently verify that a given check is selected for payment before the check is even 
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received. For instance, the merchant may send SIGm(2001.01 .01) at the beginning of January 1^, 
2001, or even before it, and then just send the bank all checks relative to January 1^', 2001. 
Although convenient, this may not be prudent for the merchant, however, since if a malicious 
user were to gain possession of SIGm(2001.0L01) during January 1^, 2001, she could write 
checks that day that would never be selected for payment. There are many variations of this 
approach (such as using a time granularity of one hour rather than one day) that are obvious to 
one skilled in the relevant art. 

In one form, the second embodiment of the present invention allows the merchant to 
associate an item (substantially unpredictable to the user), using the time/date information on a 
check C, by deriving a sequence of values VLi. The merchant derives a sequence of values VLi 
associated with a sequence of times ti (i = 1, . . . , n), at least one of which is related in a given 
manner to the time t of the transaction T. For instance, at least one integer m greater than 1 and 
less than n, |t - tml is less than a predetermined amount, for example one day. Alternatively, for at 
least one integer m between 1 and n, t- tm (or tm-t) is both positive and no greater than a day. 
The user causes the merchant to receive at least a portion of C that iucludes information 
regarding the time t of the transaction T. 

The merchant then determines whether a property P holds between the portion of C, and 
the value VLm. or between the portion of C and a quantity Q depending on the value VLm 
associated with tm- If so, the merchant causes the bank to receive information I that enables the 
bank to verify that the property P is satisfied, so that the bank can make appropriate credits and 
debits. 

In one form, the merchant may associate an item V (substantially unpredictable to the 
user) to each check C using the date information of C, by generating a chain of hash values. In 
this form, the merchant generates the chain of values: 

Wo, wi. . . . , Wn, 

where Wi « h(wi+i) and h is a one-way fiinction, and puts wo in his public file, or digitally signs it, 
or otherwise makes it public. The merchant thus associates Wj+i to the i-th date/time urdt. The 
associated item Wi+i is unpredictable, even if the merchant reveals all items associated to prior 
time units. Although the first i such items may have been released by time unit i, Wi+i is 
I substantially unpredictable, because one cannot compute Wj+i by just knowing Wi=h(wi+i). The 
unpredictable item V that the merchant associates to a check C having time/date information i is 
Wi+i, i.e. the i-th hash inverse of the time/date information. The property P may then be 
formulated in a variety of ways. As one example, the property P may be satisfied if the first 10 
bits of Wi equal 10 selected bits of C. The merchant can enable the bank to verify whether 
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property P holds by simply releasing the infonnation I=Wi. The bank can verify Wi by hashing Wj 
i times and seeing whether the result matches the merchant's wq, and then verify whether P holds. 

It should be noted that if the merchant uses an unpredictable item V associated with the 
date/time information on the check, then it is better for the merchant to hide any information 
about those checks that he has discarded and those checks he has set aside for credit during a 
given day/time unit. Else, a malicious user may prematurely discover the values V, and use this 
information to his advantage, for example by generating checks that he knows will not be 
selected. It is preferable for the merchant to set aside all "selected" payable checks of a given 
date/time unit, and then send all the selected checks to the bank at the end the date/time unit. In 
this way, even a malicious bank cannot collude with a user so as to enable him to defraud the 
merchant. Security may also be enhanced by requiring users to utiUze smart cards, cell phones, 
or other devices that make it difficult or impossible for a user to freely generate and test a variety 
of checks to determine which checks will turn out to be selected for payment, 
in, Micropavment System Includiag A Selective Deposit Protocol That Eliminates User 

Risk 

It is typical of probabilistic payment schemes that the user does not know in advance, and 
has no control over, which of his checks will be selected for payment. In the embodiments of the 
present invention, as described so far, it may happen that a user is debited by an amount that 
exceeds what he actually spent, i.e. by an amount that exceeds the sum of the values of the 
checks he has written. In a traditional probabilistic payment scheme, if a check Q is selected to 
be payable with a probability s, then the user is typically debited for more than the transaction 
value TVi: in many probabilistic schemes, he is debited by an amount (TVi * 1/s), by way of 
example. Thus, if each transaction Ti has the same value TVi=TV, and by bad luck two or more 
(rather than one) of the user's first 1/s checks become payable, then the user would be debited by 
an amount that is at least twice the actual amount that he spent. When s is large, this may be 
expected to happen for approximately one-quarter of the users. 

In a third embodiment of the present invention, a selective deposit protocol is featured, 
which solves the problem of user risk, namely the possibility that a user by bad luck may be 
charged more than the. total value of the checks that he has actually written. The problem of user 
risk is inherent in probabilistic micropayment schemes, such as Rivest's electronic lottery 
scheme, and the micropayment system disclosed in the previous section. For example, even 
though the selection rate s for a probabilistic scheme may be 1/1000, it may happen that by bad 
luck five, rather than one, of user's first 1000 payments are selected for payment. While the 
probability of excessively charging the user is small, and while the relative impact of user risk 
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decreases dramatically with the number of micropayments made, user risk may constitute a 
strong obstacle to a widespread acceptance of probabilistic raicropayment schemes. This is 
because ordinary users are not accustomed to managing risk, unlike larger institutions such as 
banks. Accordingly, the mventive scheme of the third embodiment, described below, improves 
the underlying probabilistic payment scheme. 

Figure 4 provides, in flow-chart form, an overview of the method for raicropayment 
transactions in accordance with the present invention, which includes a selective deposit protocol 
that eliminates the risk to the user of excessive payment. In this embodiment, a method and 
system is featured, which enables a user to establish payment for a series Ti (i = 1, . . . , n) of 
transactions. Each transaction Ti is typically characterized by a transaction value TVi that is very 
low, for example one cent or a fraction of a cent. The bank would therefore incur processing 
costs much liigher than the transaction value TVj itself, if the bank were to process every single 
transaction Tj. 

A probabilistic micropayment scheme (e.g., Rivest's lottery scheme, or one of the 
schemes set forth in the previous sections) can therefore be used by the user to generate for each 
Ti a check/micropayment Q, which is sent to the merchant as payment for the transaction Tj. 
Then, with probability greater than 0 and less than 1, it maybe determined whether Ci is selected 
for payment, either by an interaction of the user and the merchant, as in Rivest's lottery scheme, 
or non-interactively by the merchant alone, as in the schemes described in the previous section. 

As seen from Figure 4, for each Ci (i = 1, . . . , n), the user causes the merchant to receive 
Q. For each Q that the merchant receives, the merchant determines, in accordance with the 
underlying probabilistic scheme and in a maimer that prevents the user from predicting in 
advance which checks will be selected for payment, whether Q is selected (i.e. payable). For 
example, the underlying probabilistic scheme may be the scheme described in section I above, in 
which case the merchant will detemrine payabihty by associating an item Vi with Q, and 
determining whether Vj satisfies a property Pi. The merchant may possibly check other 
conditions, such as whether the user's signature on Q is vaUd, whether the amount of the check 
is not too large, and so forth; some of these conditions may be specified in the user's certificate. 
If the merchant determines that Cj is not payable, the merchant discards Q. If the merchant 
determines that Q is payable, the merchant causes the bank to receive information li, which 
enables the bank to verify that the selected check Ci is payable. The bank uses li to verify that Ci 
is payable. If and only if Q is payable, the bank causes the merchant to receive a credit amount 
CRi, and the user to be debited by an amoimt Dj. 

In the third embodiment of the invention, the bank must ensure that Dj is such that the 
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total amount D = Di + D2 + . . . + Di debited to the user is no greater than the total aggregate 
value Tagg = TVi + TV2 + . . . TVj of the checks the user has written. In other words, the total 
amount that a user is debited after he has participated in i transactions, for any integer i such that 
1 < i < n, must never exceed the aggregate value of the transactions Ti, . . . Tj that he has 
purchased from merchant. 

In a preferred form, the bank determines Dj, in a manner that guarantees D = Di + D2 + - . 
. + Dj to be no greater that Tagg, by using serial nimibers from the checks. In this form, each of 
the plxiraUty of checks Ci (i = 1, . . . , n) generated by the user in the underljdng probabilistic 
payment scheme includes a serial number Sj. These serial numbers Sj are preferably consecutive 
integers starting from 1 . Also, the /-th serial nimiber is preferably representative of the order in 
tune of the transaction Ti and the check Q, relative to the other transactions (Ti, , . . , Ti-i, and 
Ti+i, . . . Tn) and the other checks (Ci, . . . , Cm, and Q+i, . . . Q,). 

The serial number Si provides an indication of the index i associated with the transaction 
Ti and/or the check Ci. Ordered but non-consecutive serial niombers can also be used, however. 
For example, one may associate with the i-th check the i-th prime nimiber, after a given niunber 
P. For simplicity, the case in which each transaction Ti has the same transaction value TV=TVi 
will be described first. The third embodiment also encompasses cases in which the transactions 
Ti may have different values TVi, as discussed in more detail later. 

The bank (or another fifth party) keeps track of the serial numbers of the checks that have 
been selected for payment. In order to determine the debit amount Dj of a payable check Q, the 
third/fiftti party uses the value Smax, where Smax denotes the serial number appearing on the most 
recent check that has been presented, so far, for payment. The value Smax is initialized to zero in 
the case that the serial numbers are used sequentially starting with 1. Because the serial numbers 
on the checks are sequentially ordered, Smax is the largest of the serial numbers appearing on any 
check that has previously been presented for payment. Also, Smax is less than the serial number 
Si of the current payable check Ci, because of the sequential ordering of the serial nimibers. As 
shown in Fig. 4, the user is debited (e.g., by the fifth party) for this check by an amoimt 

Di = (Si-Smax)*TV. (1) 

It follows that the total amount D the user has been debited for all of the checks he has written is 
Si * TV. If non-consecutive serial numbers are used, one may define Di = #(Si - Smax) * TV, 
where #(Si - Smax) denotes the niunber of serial numbers between Sj and Smax (inclusive of Si but 
exclusive of Smax). 

The amount D = Di + D2 + . . . Dmax represents the aggregate value of all the checks that 
user has issued. Since D is never more than i*TV after i checks have been written, the risk to the 
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user of making an excessive payment is thus eliminated. In order to process future 
micropayments, the bank then resets the value of Smax to Si, which as explained above is the most 
recent check found by the bank so far to be payable. Equation (1) also shows that the amount 
ultimately charged to the user does not depend on which checks ultimately turn out to be 
payable, but only on the number of checks that the user has written; the user is eventually 
charged the proper amount for each check he has written. 

The fifth party may cause a fourth party (which may be the merchant, or may be an entity 
other than the merchant) to receive a credit amoxmt CRi, which typically is given by: 

CRi = TV * (1/s). (2) 
If there is a selection rate s in the underlying probabiHstic payment scheme, then also in the 
method and system of the present invention, approximately only 1 out of every 1/s checks 
becomes selected for payment, when averaged over a large number of micropayments, 
Accordiagly, the credit amount is fair to the merchant, too, siace it is the full aggregated value of 
the 1/s checks, and the merchant ends up receiving the correct amount, when an average is made 
over a large number of micropayments. But the resulting scheme is much fairer to the user, 
because the risk of making an excessive payment is shifted from the user to the bank. For 
example, if the selection rate is s = 1/1000, and the merchant deals with 1,000 micropayments, 
each worth one cent, then it is expected that only one of these 1,000 payments will be selected, 
but the selected one will cause the merchant to receive 1/s = 1000 cents, or $10. If more than 
one micropayment (out of 1,000 micropayments) is selected, the bank will, by bad luck, have to 
pay $10 more than once. The bank may choose to shift some risk to liie merchants by deferring 
payment on a check to a merchant until the user has paid enough in aggregate, according to the 
serial-number debiting scheme described above, to cover the payment of this check and of all 
previous checks also selected for payment. 

In this third embodiment of the invention, the user may preferably have obtained a 
certificate from his bank authorizing the user to write checks on the user's account at the bank. 
This certificate may specify the user's public key; it may also specify other information such as 
the maximum serial nimiber the user is authorized to use, and/or the maximum amount of a 
check (if the checks may have variable value). The user may send this certificate with each 
check he writes, or may only supply it to merchants to whom he has not sent it recently. Some 
bandwidth savings can be obtained by haviag the merchants cache the user certificates for a 
certain amount of time. 

In another variant of this embodiment of the invention, the maximum serial nimiber Y the 
user is authorized to use may be specified by using a hash chain of length Y, ia a manner similar 
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to the way in which a Pay Word certificate specifies the root of a hash chain of length Y 
authorizing a sequence of Y micropayments to a particular merchaat. In this case, however, the 
checks with the authorized serial numbers may be written to any merchant. The user can supply 
the merchant with the certificate and the i-th element of the hash chaia to prove that he is 
authorized to write a check with serial number i. (The i-th element of the hash chain is defined 
to be the element of the hash chain which,' when hashed successively i times, yields the root of 
the hash chaia.) 

The merchant may also have a digital certificate, which the user may or may not obtain 
during the payment protocol, depending on which version of the protocol is used. If the payment 
protocol is indeed non-interactive, the user may have difficulty obtaining this certificate. On the 
other hand, this certificate is not essential for the payment protocol. For example, the user's 
check could include a statement of the form 'TTiis check is only valid when deposited in 
conjxmction with a valid certificate for the merchant's public key," or the Hke, and the merchant 
could supply the bank with its certificate when it deposits the check. ' 

For several reasons, it is preferable to shift the risk of excessive payment from the user to 
the bank, or to the merchant. First, the probability that checks are selected significantly more 
often than one out of 1/s times is small. Thus, excessive payments by the bank occur only rarely. 
In any event, the amount of each such excessive payment is quite modest. The bank can also 
adopt strategies such as charging each user a fixed fee (for example, a fee proportional to 1/s) 
when opening an accovmt, to cover such variations. While a sniaU risk of a moderate amount of 
excessive payment may bother individual users, and discourage them from signing up with 
probabilistic micropayment schemes such as the one disclosed in the present invention, such a 
risk will generally not bother banks. The reason is that banks are accustomed to managing 
substantial risk. As just one example, a risk routinely managed by banks is the risk of borrowers 
defaulting on their loans. Thus, banks are institutionally well-suited to supporting payment 
systems wherein they can make a profit by accepting and managing risk. 

Similarly, merchants are typically used to managing large numbers of transactions, where 
each transaction has some associated risk, such as the risk that the goods will be returned or that 
the user's payment will not materialize. Therefore, it may also be acceptable to the merchants to 
accept some risk in a micropayment scheme. The bank and the merchant might thus agree, for 
example, that a micropayment check selected for payment will not actually be paid to the 
merchant until the user's account contains sufficient fimds to cover it. Each check selected for 
payment would be held in a "pending queue" at the bank imtil the user's payments (determined 
according to the serial-number scheme described above) are sufficient to cover this check and all 
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previously queued checks. 

Second, the probability of an excessive payment becomes less and less in the long run, 
i.e. the risk decreases as the number of micropayment transactions increases, as long as there is a 
small per-transaction fee levied by the bank, no matter how small. The probabihty of excessive 
payments is therefore smaller for a bank, as compared to the probability for an ordinary user, 
because banks generally experience much higher volumes of transactions, as compared to a 
single user. 

Besides eliminating the risk of excessive payment by the user, the third embodiment of 
the present invention also enables the bank to punish cheating parties, or purge them from the 
system before they can create any substantial damage. As explained in more detail below, the 
present invention includes several features that permit the bank to prevent a malicious user 
and/or a malicious merchant from cheating. For instance, if the bank notices that a new check 
has the same serial nmnber as a previously processed check, or if the new check's serial nvmiber 
and time are somehow out of order with respect to previously processed checks, or if the amount 
of the check is excessive, or if other bank-defined conditions occur, then the bank can refuse to 
honor the check. The bank may even fine the user, and/or take other punitive actions, as it 
deems appropriate. For instance, the bank may keep statistics and throw out of the system - e.g., 
by revoking their certificates if certificates are used - users whose payable checks cause any of 
the problems described above. For example, checks may be thrown out if they are inconsistently 
numbered and/or dated, or if they belong to users whose checks are more frequently payable than 
expected. Similarly, the bank may throw out of the system merchants who misbehave, such as 
merchants who receive for payment checks with the above-mentioned problems, or checks which 
are more frequently payable than statistically expected. 

In the third embodiment of the present invention, users are required to use the serial 
numbers in order, and without repetition. For example, serial number 1 should be used for the 
first check, serial nimiber 2 should be used for the second check, and so forth. As described 
above, in this way the user will never be charged more than he should. Typically, at a given 
time, after the last payable check he will have written a few more checks for additional 
transactions which were not selected for payment. Therefore, at least for a while, he is debited 
less than he actually spent, and occasionally will be debited by exactly the amount he should be 
debited, i.e. when the latest check is actually payable. 

A dishonest user, however, may try to play with the serial nxunbers so as to find ways to 
be debited by an amount less than what he actually spent. One way is to re-use a serial number 
more than once. If he does this, the quantity Si - Smax and thxis the amount given by (Si-Smax)*TV 
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will be reduced, compared to its true value. This Idnd of cheating will not be very useful, 
however, because if the bank notices that a payable check has the same serial nimiber as a 
previously processed check, the bank could take punitive measures designed to prevent such 
cheating. For example, if the bank encounters a duplicate serial nxmiber in a payable check, the 
bank could be authorized to debit the cheating user an amount so high that it will be 
cbunterproductive for the user to in cheat this way. 

It should be noted that in the micropayment scheme featured in the third embodiment of 
the present invention, the user cannot predict and thus cannot control which of his checks will 
become payable. Thus each time he generates two checks having the same serial number, there 
is a chance, albeit small, that both of them will become payable. The penalty for being caught 
cheating can be set high enough that it more than offsets what he could hope to gain by cheating. 

Several forms of cheating may involve **back-dating'* of checks and the Uke. It is thus 
important for the merchant and the bank to check that, for any two checks C and C seen from 
the same user, if the serial number of C is less than the serial number of C\ the date/time of C is 
before the date/time of C\ 

The above-described mechanism for catching a user who is cheating works better if the 
user is not told by the merchant which of his checks become payable, immediately after the 
payment transaction. In fact, from this view point, it would be preferable to keep the user as 
ignorant as possible about which of his checks has become payable. In principle, the user can in 
fact monitor exactly how many checks he has written, and thus will not dispute an honest debit. 
However, if a dispute should arise, then the abiUty to present proof of the amount debited, 
including the serial number of the payable check, would be desirable. 

The above-described mechanism for searching out and throwing out cheating users can 
be unproved, if the criterion for selecting a check Q for payment depends solely on the serial 
number Si. In this way, if a check is payable, so is any other check which is generated with the 
same serial number by cheating. For instance, if the underlying probabilistic payment system is 
as disclosed in the previous section, the quantity Vi (unpredictable by the user) used to determine 
(via the property P) when a check is payable, can simply consist of the merchant's signature of Si 
alone, together perhaps with the user's account number and/or name, rather than the merchant's 
signature of the whole Q. 

Another way in which the user may try to pay less is to use serial numbers in a sequence 
that is out of order with their times of use. For instance, once a malicious user becomes sure that 
Sioo is the lowest serial number of a payable check, he may plan to start re-using serial numbers 
Si through S99. so as to be assured that the checks he uses will not be selected for payment, while 
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at the same time not fearing that he will be caught using the same serial number twice. Even 
with this kind of game plan, however, the malicious user still has a good chance of being caught. 
The reason is that if he later (i.e. after usiug Gioo) re-uses a serial number between 1 and 99, he 
cannot prevent the illegitimate check from becoming payable. This will occur with some 
positive probability, and, if it does, the bank will notice that check Cioo was payable relative to a 
transaction Tioo having a time tioo^ and that the user has later generated a check having a serial 
number less than Sioo for a transaction whose time is later than tioo- Again, the resulting sanction 
by the bank may make it counterproductive for the user to cheat this way. In order for this kind 
of screening mechanism to work smoothly, it is preferable that each check carry an indication of 
the time of the transaction it pays for, and that the merchant disregard as invalid, before the 
selection process begins, those checks carrying a wrong time-indication. 

To support this anti-fraud strategy better, the bank may require merchants to use a 
selection procedure that is designed to contain, by way of example, both a component that 
depends only on the serial number of the check, and a component that depends only on the time. 
Another component could depend on the entire check. In essence, there could be two or more 
selection procedures, and the check may be selected if the outcome of any one of them 
determines the check to be selected. Such variations should be obvious to those skilled in the 
relevant art. 

A malicious user U' could also collude with a malicious merchant M*, so as to ensure that 
a check signed by U' and spent for goods/services/ioformation provided by M' is always payable. 
This way, assimnng for simplicity that each payment value is 1 cent, U* will always be debited 
just 1 cent by the bank, while M' will always be paid 1/s cents (i.e., $10 if s=l/1000). Then U* 
and M' may share their illegal proceeds: indeed, U' may coincide with M' if he sets himself up as 
a merchant (perhaps under a pseudonym)! 

Nonetheless, U' and M' may only make a modest illegal gain: if they try to boost their 
illegal gain, by repeating the above-described method several times, they are likely to be thrown 
out of the system. This is a high price to pay, particularly if M' also has legitimate gains in the 
system. If it is not easy for thrown-out users and merchants to come back in the system, e.g., 
under a new identity, or if the price needed to enter the system in the first place (e.g., the price 
for obtaining an initial certificate) is sufficiendy high, this illegal game pays little. It may even 
have negative returns to the user, and the costs involved may easily be absorbed by the bank. 

In any case, this kind of cheating may be eliminated by having the first party use secure 
hardware. This untamperable component may, for instance, be responsible for properly 
incrementing the serial number each time a new check is generated, and possibly also for 
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keeping safe the secret signing key and for generating the signature component of a new check- 
Thus if a malicious user tries to generate a check that is payable to his merchant accomplice, at 
every trial he must also increase the serial nimiber. Thus, once a payable check is generated, the 
merchant will be paid a given amount, but the user will also be debited a corresponding proper 
amount. It should be noted that anywhere in this disclosure a party may use, and/or be required 
to use, secure hardware for performing at least part of its operations. Such secure hardware may, 
in particular, be included in a smart card or mobile phone. 

A small probability exists that an honest user may appear to be malicious, because after 
he writes n checks, significantly more than n*s of them have become payable, just by chance. In 
this case, he may be thrown out. With appropriate parameter settings, there will be very few 
such users. In addition, it is possible to communicate to these users that they unintentionally 
caused losses to the bank. For example, the bank can present the users with infomiation that 
reveals that an unusually large number of their checks were found to be payable, and that 
explains why so many of their checks actually were payable. As a consequence, these users may 
accept to stay in the micropayment system under different conditions - for example, as users of a 
probabilistic payment system in which the user bears the risk of being debited by an amomt 
greater than the amoirnt he actually spent. Such a transition mig^t even be incorporated as an 
automatic feature in the original agreement between the user and the bank. 

As noted earlier, the bank may shift to the merchant some of the risk associated with 
statistical variations, and now also some of the risk associated with user cheating, by deferring 
payment of checks selected for payment until such time as the bank has received from the user 
sufficient fimds to cover this check (and all previous checks from that user selected for payment). 
The bank will be receiving funds from the user systematically according to the number of checks 
the user has written, and the bank will be receiving checks from the merchant that have been 
selected for payment, according to the present invention as described above. When the user is 
honest and writing checks frequently, the merchant in this scheme should not have to wait long 
for payment from the bank. Also, if the bank pays the merchant not the fiiU value of each check, 
but a slightly discounted amoxmt, then the user's account should typically be paid up (or nearly 
so), as the rate of user payments will somewhat exceed the rate of bank disbursements. In fliis 
case a merchant should expect payment immediately or only after a short delay. Shifting risk to 
the merchant in this manner may be a particularly effective way of discouraging users and 
merchants from attempting to collude in an effort to defraud the bank, since the bank no longer 
assumes any risk that the disbursements made for the user's checks selected for payment will 
exceed the receipts from the user. If this variation is adopted, it may be usefiil for the bank to 



36 



wo 02/088874 PCTAJS02/12189 
indicate in the user's certificate the total value of the "pending, unpaid" checks associated with 
the user's accoiint, so that a merchant may decline to accept a user's check if this amount seems 
excessive. 

The method and system of the third embodiment of the present invention also enable one 
to handle micropayments that do not have a uniform, fixed transaction value. One method would 
be to treat a check worth v cents explicitly as a bundle of v one-cent checks, with consecutive 
serial numbers. A more efficient method is for the user to write a single check that is 
characterized by a serial number interval, [S, S+v-1] (inclusive of both endpoints S and S+v-1), 
instead of being characterized by a single serial nxnnber. If this check becomes payable, the user 
will be debited by S+v-1 -Smax cents, and the new Sjnax will become S+v-1. 

In this third embodiment of the present invention, the process by which a check is 
determined to be payable may depend on the value of the check, when checks of varying value 
are supported. That is, instead of a single selection probability s, there is a selection probability 
Sv for each integer v greater than zero, and these probabilities may differ. The procedure may 
use a simple "step function" of the fomi: a check for v cents is payable with probability 1/100 if 
V is less than 100, and with probability one if v is 100 or greater. Alternately, a "ramp function" 
could be used: a check is payable with probability v/1000 if v is at most 1000, and with 
probability one if v is at least 1000. However, the use of schemes may interact unfavorably with 
the ability of the bank to detect various forms of Jftaud, so they should be used with caution. For 
example, the bank can no longer so easily predict the amount that should have been paid out to 
merchants so far, given only the maximum serial number seen. For this reason, it may be 
desirable to keep the selection probability fixed. In this direction, one attractive approach would 
be for the bank to issue to the user two or more certificates, each certificate specifying its own 
set of allowed serial numbers, its own maximum payment size, and its own selection probability 
s. In essence, the user then has a set of distinct "checkbooks", each with its own parameters and 
limits, but each with its own selection probability s. 

Referring to the non-equal transaction value case in more detail, the third embodiment of 
the present invention allows a user to establish payment for a plurality of n transactions Ti, T2, . . 
. , Tn, where each transaction Tj is characterized in part by an integer index i and a transaction 
value TVj, and where each Tj need not be of equal value, but each T Vj can be characterized as a 
multiple of a common unit value UV. UV may be, for example, 1 cent. In this case, each data 
string Ct includes information on the integer index i, and the value TVi of Ti. The information 
takes the form of a pair of values (Si, Si + Vi-1) consistmg of the "initial serial number" and "final 
serial number" for that check. For all i between 1 and n. Si is a progressive serial number that is 
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sequentially ordered, and that is representative of a position of Q relative to other data strings in 
an ordered succession of data strings Cj Q = 1, . . . , n). Vj is an integer depending on i and 
indicative of the value TVi of Ti, and is given by Vi = TVi / (UV). 

The merchant selects from the received checks Cj(l<j<n) those that are payable in a 
manner that prevents the user from predicting in advance which checks Cj will be selected to be 
payable. In one form, the merchant may use the method described in section I, namely 
associating an item Vj (such as the merchant's digital signature of Q produced using the 
merchant's secret key) with Cj, that is substantially vmpredictable to the user. The merchant 
causes a third party to receive information Ij enabling the third party to verify that a selected 
check Cj is payable. The third party, in response to receipt of Ij, verifies that a selected check Cj 
is indeed payable. If and only if Cj is payable, and perhaps if some other conditions are met as 
well, a fifth party determines the value of Smax and Vmax, where max is an integer such that 1 < 
max < i < n, and v^ax = TVmax / (UV). Smax represents the largest final serial number of any 
check selected so far for payment. Tlie fifth party then causes a fourth party (who is the payee, 
and may be the merchant or another party) to receive a credit amount CR, The fifth party causes 
the first party to be debited by a debit amount related to Dj, where D\ is given by: 

(Si+ Vi -1- Sn,ax)*UV. 

Snax is then set to be Si + Vi — 1. 

Cheating in the case of non-imifonn transaction values is caught, and dealt with, using 
methods similar to the case of fixed transactional values. For instance, two payable checks, one 
for a single cent and characterized by a serial number S* between S and S+v-1, and another for v 
cents and characterized by a serial number interval [S,S+v-l], would in this case be considered a 
proof of cheating. Checks for too high values of v may be disallowed, i.e. always refused 
payment. Otherwise, a malicious user could join the payment system, write a single check for a 
huge amount, and, if it turns out that the check was not selected for payment, never generate a 
second check. This issue can also be dealt with by charging each user an "initiation fee" when 
he estabUshes an account, such an initiation fee being large enough to cover the expected 
maximum "float" for that user. Here the "float" is the expected maximum value in checks which 
the user has written but which the bank has not seen. For some forms of this invention, this float 
can be computed as the maximum size of a check that the user may write, times the 
multiplicative inverse of the probability that a check will be selected for payment. The bank may 
also discourage cheating, as noted earUer, by deferring payment on checks selected for payment 
until the bank has received sufficient funds from the user to cover this check (and previous 
checks written by the user that were also selected for payment). 
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In one fonn, the method and system of the third embodiment, which guarantee that a user 
is never charged more than what he actually spends, can be implemented with an underlying 
probabilistic payment scheme that has been described in the section I. In this case, upon 
receiving a check Ci for a transaction Ti (i = 1, . , . , n), the merchant associates with the check Q 
an item Vi that is substantially unpredictable by the user, for example the merchant's digital 
signature for d or for a portion of Q, SIGmCCO, created using the merchant's secret key. The 
merchant then determines whether satisfies a certain property Pi, for example the following 
property: 

F(SIGM(Ci))<s, (3) 
where F is a function that operates on a bit string and retums a nmnber between 0 and 1, and s is 
the selection rate (0 < s < 1). 

If merchant finds that Vi does indeed satisfy Pi, the merchant causes the bank to receive 
the information li that enables the bank to also verify whether Vi satisfy Pi, for example the 
merchant's public key corresponding to the merchant's secret key that was used to generate Vi. If 
Vi does not satisfy Pi, the merchant discards the check Q. If and only if the bank finds that Vi 
does indeed satisfy Pi, and perhaps that Vi also satisfies other conditions determined at the 
discretion of the bank, a fifth party (which may be the bank, or an entity other than the bank) 
causes a fourth party (which may be the merchant, or an entity other than the merchant) to 
receive a credit amount, CRi. The fifth party also causes the user to be debited by a debit amount 

In the third embodiment, the amount Dj charged to the user is not necessarily tihe same as 
the amount CRi received by the merchant (or other entity). However, the method of the third 
embodiment distinguishes itself firom the underlying probabiUstic payment scheme, by including 
a selective deposit protocol, which ensures that the amount Dj by which the user is debited is 
never more than the amount that the user has actually spent, in the aggregate, by writing his 
checks. More specifically, the selective deposit protocol guarantees that, in aggregate, the 
debited amounts are always no greater than the corresponding transaction values. In other 
words, the user is assured of never being charged in excess of what he actually spends. 

Figure 5 provides a schematic block diagram illustrating the components of a 
micropayment system 200 for establishing payment for a transaction Ti, in accordance with the 
third embodiment of the present invention. The system 200 includes communications means 210 
that permit the user, the merchant, and the bank to transmit electronic data, and even payments, 
among themselves. The electronic data may include data strings that represent electronic checks, 
or strings that represent messages. In one embodiment, the conununications means 210 may 
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permit access to remote servers. The coromunications means 210 may include a modem, and 
one or more network interface devices known in the art, including but not linfiited to network 
interface cards. One or more buses, for example address bus 214 aad data bus 215, may be 
provided so as to permit transfer of data between different network nodes. 

The system 200 also includes a first processing means 205, aad a second processing 
means 206. The first and second processing means may be computer systems, for example 
digital computers running a DOS or Windows operating systems, and are connected to the 
address buses 214 and the data buses 215. Each of the processing means 205 and 206 typically 
includes storage means 221 for storing data, input means 222 for inputting data, and a Central 
Processing Unit ("CPU") 223 that implements the system commands. The storage means 221 
may include a computer memory, and a data storage device such as a hard disk, a CD-ROM, and 
the like. The input means 222 may be any input device known in the art, for example a 
conventional keyboard. 

The first processing means 205 is operative by the user for deriving, inputting and storing 
a data string Ci related to a transaction Ti (i = 1, . , . , n), including in the data string Ci a 
progressive serial number S\ that is representative of the position of the check Q relative to other 
checks in an ordered succession of checks Cj (j = 1, . . . , n). The second processing means 106 
is operative by the merchant and responsive to Cj, for associating an item V,- with Q. The second 
processing means 106 is also operative to determine whether V,* satisfies a property ?,-. For 
example, a set of instructions can be inputted into the CPU 223 of the second processing means 
206, to cause the CPU to derive the item Vi associated with Ci (or a portion of Q), and to cause 
the CPU 223 to determine whether Vj satisfies a property Pi. This is a necessary condition that 
must be satisfied, in order for the next step to be executed by the CPU 223 in 206, namely the 
ordering of the transfer to the bank of information li enabling the bank to verify whether Vi 
satisfies Pj. The CPU 223 in the processing means 206 can be programmed to be selectively 
operative when Vj satisfies Pi, to transmit the information I, to the bank. 

The system 200 also includes means 240, selectively operative by the bank (or another 
fifth party) when Vi satisfies Pj, for causing a fourth party (which may be the merchant, or 
another entity) to receive a sum of money. The means 240 may also be a computer system, 
having a CPU that can be programmed to be selectively operative when Vi satisfies Pj, to: 
1) determine the value of Smax, where S^ax is the serial niunber of the last check upon which 
payment was made (and thus the largest of the serial numbers on any check presented to the bank 
so far for payment); 2) order the transfer of a payment of amount CR to a fourth party; and 
3) cause the user to be debited by an amount D. 
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In sum, the micropayment system and method of the third embodiment of the invention 
provides a mechanism for guaranteeing that the user never be charged more than what he 
actually spends. In this way, the system and method presented in the third embodiment 
significantly enhances user acceptance, which is a key factor in effecting widespread acceptance 
of micropayment schemes. 

IV- Micropayment System Including A Deferred Selection Protocol Controlled Bv The 
Bank 

The fourth embodiment of the present invention features a probabilistic micropayment 
scheme including a deferred selection protocol, in which the payment selection process is 
deferred until the bank receives firom the merchant a commitment to one or more checks. There 
are several methods of accomplishing such a deferred selection protocol. A first (and preferred) 
method is as follows: A user creates a data string or "electronic check" C, derived from a 
micropayment transaction T and providing an adequate indication of the time t of the transaction, 
and sends C to the merchant, when the user wishes to make a payment. The merchant groups the 
checks Ci (i = 1 , . . . , n), which he has received from one or more users in a given time interval 
(e.g., in a given day), iato m lists L^, where k — 1, . , . , m. Here m is arbitrary, but may for 
example be an integer equal to, or approximately equal to, 1/s, where s is the desired selection 
probability. Preferably, each list comprises all the checks satisfying exactly one of m mutually 
exclusive properties, Pi,..,Pm. Por instance, if m=1024, each list (k = 1, . . . , m) includes all 
checks received that day that hashed according to a deterministic hash function H to produce a 
value whose first 10 bits are the 10-bit binary expansion of the integer k-1 . Each list L*^ (k = 1 , . . 
. , m) includes /k checks C^i, . . . C^/k, where represents the number of data strings in list 
When summed over the m Usts, /knaturally adds up to the total number n of received checks , i.e. 

/i + ... + /k+.../m =n. 
The merchant commits to each list by computing a commitment CM^ for L*^, and causes the 
bank to receive CM'^ (k = 1, . . . , m). 

As known in the art, a commitment scheme is a protocol that enables one party to deliver 
a message to another party, without revealing the contents of the message, and while being 
conunitted to this message. The protocol allows the parties to emulate the process of delivering 
the message in a "locked box," whereby the sending party (in the present case, the merchant) can 
prevent the receiving party (in the present case, the bank) from knowing anything about the 
message in the box, until such time ia the future when the receiving party is given the key to the 
box. The receiving party, on his part, can prevent the sending party from changing the message 
in the box, after the receiving party has already received it A commitment scheme is typically 
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comprised of two phases: the first phase (the "commitment phase") sunulates the delivery of the 
locked box. When this phase is completed, the receiving party does not know the message yet, 
but the sending party cannot change it any more. The second phase (the "de-commitmmt 
phase") simulates the delivery of the key. The receiving party can now see the message, and 
verify that the message in the unlocked box is indeed the message to which the sending party 
committed himself 

In a preferred form, the commitment CM^ for may be a hash value H(L^), where H is a 
one-way collision-resistant hash function. Therefore, it is computationally infeasible to derive 
from CM^, and it is also computationally infeasible to produce two diJSerent strings Li^ and Lz^ 
such that H(Li^) = H(L2^). 

In the deferred selection protocol featured in the fourth embodiment of the present 
invention, the payment selection process for determining whether or not a particular check Q 
should be selected for payment is deferred until the bank receives the merchant's comnaitments 
CM^ (k = 1 , . . . , m) to the lists L^. This is a distinguishing feature of the micropayment scheme 
described in the fourth embodiment of the present invention. Upon receipt of CM*^ (k 1, . . . , 
m), the bank selects one index k between 1 and m in a manner unpredictable to the merchant and 
to the users. For instance, the bank may digitally sign the day in question (e.g., 2001.01.01), and 
then use for selection the j5rst 10 bits of this signature. This signature could be hashed before the 
JBrst ten bits are extracted. The bank*s signature can be published (e.g., posted on the Web) so 
that everyone can verify that k is indeed the index selected by the bank that day. The selected 
index k is the paying index. The merchant responds by de-committing CM^ into the original Ust 
of checks L^. Alternatively, the bank may compute an index k as a function of the merchant's 
commitments CM*" (k == 1, . . . , m) to the lists L\ For instaoce, k could be extracted from the 
bank's signature of CM^ . . . CM"" or H(CM' . . . CM"" ) where H is a one-way hash function, or 
f(CM^ . . . CM"* ) for some given function £ 

The bank then inspects that all is proper. For example, the bank verifies that the checks 
in the de-committed list are indeed relative to the day in question, that there are no duplicate 
checks in the list, and that all checks in the list satisfy property Pk, that the user signatures, if 
present, are valid, and so forth. If any of these conditions are not met, the bank may fine or take 
other punitive measures towards the merchant (or the users, as the case may be - e.g.^ because the 
bank discovered tliat a user has signed two checks with the same serial number). Otherwise, the 
bank pays the merchant m times the aggregate value of the checks in L^. Altematively the bank 
may pay the merchant the aggregate amount of aU checks in all lists if the inspected Ust 
satisfactorily passes inspection. Some of these payments could also be deferred, as described 
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earlier, if the user's account has insufficient funds to cover these checks. 

The users whose checks belong to are then debited in one of several possible ways. 
For instance, these users can be debited m times the face value of their selected checks (as in the 
first embodiment) or according to the serial numbers of their selected checks (as in the third 
embodiment). The bank may exercise scrutiny or mete out punishment in ways envisioned in the 
prior embodiments. The bank may also ask the merchant to de-commit additional lists to verify 
that all is proper, or to select more than one paying indices. In the latter case, the bank may pay 
the merchant m/r times the aggregate value of the checks in L\ where r is the number of Usts 
selected for payment. In this case, the selection probabihty is r/m, rather than 1/m. 
Altematively, the bank may inspect two or more Usts and then pay the merchant the aggregate 
amount relative to all checks in all Usts. 

Note that commitment can be used recursively within the scope of the invention. For 
instance, rather than sending to the bank m commitments CM*" (k = 1, . . . , m) to the Usts 
(k=l,. . .,m), the merchant can send the bank a commitment to these m commitments. By way of 
example, the merchant may send the bank a single value C= H(CM^ . . . CM"" ) where H is a one- 
way hash function. After the bank selects one (or more) index k, the merchant may first de- 
commit C so as to reveal what CM^ was, and then de-commit CM^ as before by revealing the 
corresponding list of checks. For instance, if C= H(CM^ . . . CM"" ), then the merchant may 
reveal the right value for CM^ by reveaUng all m coromitments CM^ . . . C3Vf". The bank may 
one-way hash these m values to check that the same value C= H(CM^ . . . CM"" ) is produced, and 
then retrieve the kth commitment so as to isolate CM^ Of course, the merchant could also 
commit to the m commitments CM^ . . . CM"* by sending the bank not a single commitment C but 
a pluraUty of commitments. For instance, the merchant may send a commitment to CM^ . . . 
CM^°, a second commitment to CM^^ . . , CM^°, and on. 

Typically, to commit to m values Vi . . . Vm by means of a single value V (e.g., by 
V=h(V i, . . .,Vm) for some one-way hash function h), one must reveal/send all Vi . . . Vn to de- 
commit Vi alone. This may be impractical if m is very large and/or the Vi's are very large. A 
particularly convenient method for commitment to be used in the inventive system is a 
generaUzed Merkle tree. By a "generalized Merkle tree" is meant a commitment to m values that 
enables one to decommit to just one of such values, without also decommitting to all other 
values. 

A special case of a generalized Merkle tree is the well known Merkle tree commitrnfent 
scheme described in the U.S Patent No. 4,309,569 by Merkle, incorporated herein by reference. 
One way to implement a Merkle tree is to store the to-be-committed values in the nodes of a 



43 



wo 02/088874 PCTAJS02/12189 
possibly imdirected graph G, some of whose edges could be directed so as to produce an acyclic 
(and typically tree-like) subgraph G' (preferably having the same nodes as G), and then using one 
or more underlying one-way hash functions (e.g., by using a possibly commutative one-way hash 
based on an imderlying one-way hash function) so as to store in each node a value that depends 
on the values stored at the descendents in G* of that node and possibly additional values as well. 
In this way, changing at least one or more of the original values causes the value(s) stored in one 
or more of the root nodes of G' to change as well, with overwhelming probability, unless a 
collision in one of the underlying one-way hash functions has been found. Using this method, 
the value(s) stored at the root node(s) constitute a commitment to the original values stored in the 
graph nodes. There may in addition be some constraints (that can be checked later by the bank) 
about where in the graph various values that are being committed to may be stored. In any case, 
tlie merchant can commit to CM^ . . . CM'" using a generaUzed Merkle tree. Also, a commitment 
CM^ could be generated by generalized-Merkle-tree hashing the Ust L^. Use of generalized 
Merkle trees can occur in any aspect of this invention where commitments are used. 

Note that the merchant may find it useful to send to the bank, together with the 
commitment values CM^ . . . CM"' (possibly themselves committed by one or more commitment 
C), other quantities about the list . . . L"^, such as the aggregate amounts in each of these lists, 
or the number of checks in each of these lists. These other quantities can be communicated 
outside of any commitment. For instance, the merchant may send the bank CM^ . . . CM™ . . . 
Q"", where represents a quantity of L* "in the clear." This allows the bank, by way of example, 
to evaluate ttie sum of the aggregate amounts of each list without further de-commitments. 

There are other, related methods for implementing a probabilistic micropayment scheme 
that includes a deferred selection protocol. In these methods, the payment selection process is 
deferred until the bank receives firom the merchant a cormnitment to one or more checks that the 
merchant has received from a plurality of users. The bank then determines, fairly and 
probabilistically, which of the conunitted checks should be payable. The deferred selection 
protocol of the fourth embodiment of the present invention also allows the bank to 
ptmish/eliminate cheating parties, before they can create any substantial damage. 

Figure 6 provides, in flow-chart form, a schematic overview of a method for 
micropayment transactions, in accordance with the fourth embodiment of the present invention. 
A user creates a data string or "electronic check" C, derived firom a micropayment transaction T, 
and sends C to the merchant, when a user wishes to make a payment. In the illustrated 
embodiment of the invention, a plurality of transactions Ti (i = 1, . . n) are involved. The user 
or users derive a check Ci for each transaction Ti, and causes the merchant to receive the checks 



44 



wo 02/088874 PCT/US02/12189 
Ci(i = l,...,n). 

The merchant groups the checks Ci (i = 1, . . . , n), which he has received from the users, 
into m hsts L^, wherek== 1, . . . , m. Each list (k = 1, . . . , m) includes /ic data strings C\, . . . 
C^/k where represents the number of data strings in a given Ust L^. When sununed over the m 
lists, /k naturally adds up to the total number n of received checks, i.e. 

/i + ... + 4+.../n, =n. 
The merchant then commits to each list by computing a commitment CM^ for L^, and causes 
the bank to receive CM^ for each k (i.e. for k = 1, . . . , m). 

The grouping of checks into lists maybe done according to a specific rule, agreed upon 
by the merchant and the bank. For example, the check C may be placed in a list L\ where i was 
computed as a function of C, e.g. by using the serial number of C, or extracting some bits from 
C, or extracting some bits from the hash of C. 

Each transaction Ti is preferably characterized by a transaction value TVj, Also, each 
data string Ci preferably includes data that represents the transaction value TVi of the transaction 
Ti from which Ci is derived. The merchant can thus determine an aggregate value for each list 
L^ where V^is given by: 

In other words, V"" represents the aggregate value of all the data strings C\, . . . , C^/k in the list 
L^. In this case, the merchant may also optionally commit to the values in addition to 
committing to the values That is, the merchant may provide an additional commitment CV = 
H(V\V^, . . ., V™) to the list of values (V\V^, . . V""), where H is a one-way hash function. By 
de-committing CV, the merchant thus reveals the list (V\V^ . . V"^. 

Jn the deferred selection protocol featured in the fourth embodiment, the payment 
selection process, for determining whether or not a particular check Q should be selected for 
payment, is deferred until the bank receives the merchant's commitments CM^ (k = 1, . . « , m) to 
the lists L^, and until the bank receives the commitment CV to the values V^ if this option is 
chosen. This deferral is a distinguishing feature of the ndcropayment scheme described in the 
fourth embodiment. Upon receipt of CM^ (k = 1, . , . , m) (and the optional commitment CV), 
the bank selects one or more integer indices ii, i2, . . . , in and causes the merchant to receive the 
selected indices ii, i2, • . ■ , ir- In the fourth embodiment of the present invention, the selection by 
the bank of the integer indices ii, . . . , ir represents the selection process that determines whether 
or not a check is selected for payment. 

It should be noted that the value of r is arbitrary, and up to the bank. When there are 
more incidences of attempted fraud, or when there is suspicion upon a particular merchant, a 
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larger value of r may be used. In some cases, the bank may even ask the merchant to de- 
commit all of his commitments (that is, choose r = m). Choosing r > 1 is recoromended, in order 
to have a chance to catch two checks from the same user with the same serial number, rather than 
throwing out such a user later on statistical evidence. 

Upon receipt of the indices ii, ii, . . . , ir, the merchant de-commits those commitments 
CM^ whose indices correspond to the indices ii, ii, . . . , ir that he received. In other words, the 
merchant de-commits CM^\ CM'^, . . , , CM*^ i.e. the merchant causes the bank to receive a de- 
commit string for each of the CM'\ CM'^, . . . , CM"". The merchant thereby reveals to the bank 

U^, . . L*^ if each CM^ = H(L^). If the commitment CV was previously given to the bank, 
the merchant reveals to the bank the list (V\ . . . ,V'). For those lists whose indices match the 
particular indices that the bank has selected, the bank is able to see the data strings that are 
contained in the lists, and therefore the corresponding aggregate transaction values as well. If 
CV was decommitted as well, then the bank sees the merchant's claimed aggregate transaction 
value for all lists, and not just the selected Usts. The bank can re-compute the aggregate 
transaction value for the deconamitted Usts, and compare these values to the decommitment of 
CV, in order to check for cheating on the part of the merchant. Such checking may also involve 
checking that each list only contains checks that are appropriate for inclusion in that list, and 
checking for checks appearing in more than one list. 

As a last step in the micropayment method and system featured in the fourth embodiment 
of the present invention, a fifth party (which may be the bank, or an entity other than the bank) 
carries out the payment process, i.e. causes a fourth party (which may be the merchant, or an 
entity other than the merchant) to receive a credit amount, CR. In some cases, such an action 
may be deferred imtil certain conditions are fulfilled, such as there being enough funds in the 
account associated with the creator of the check. The fifth party also causes each user whose 
checks belong to one or more of flie selected lists L*^ L^, , . ., L"", to be debited by a debit amomt 
D. 

In a preferred form, the credit amount CR received by the merchant (or other fourth party 
entity) is preferably the aggregate value V of all the checks contained in all of the m lists, namely 

CR = V = + . . . + V^ + . . . V'" . 
To implement this method of determining CR, the optional commitment CV should be used, so 
that CR can be computed from the values in the deconmiitment of CR. The amount CR that is 
paid to the merchant by the bank (or other fifth party) is thus the full aggregated value of all the 
checks that were received by the merchant and were grouped into the m lists (k = 1, . . . , m). 

In one form of this invention, the debit amount Da charged to a user U is given by a value 
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related to the aggregate value of all the user's checks contained in the lists whose indices 
correspond to the indices selected by the bank. For example, the value Dy may be determinedby 
scaling this aggregate value by the quantity m/r, the multiplicative inverse of the selection 
probability s = r/m: 

Du = (y''v + V^'u + . . . + V u) * (m/r) , 
where V^u is the total aggregate value of user U's checks contained in list L^. 

In another version of this fourth embodiment of the invention, each check Q contains 
information on a serial number Sj. Preferably, Si is a progressive serial number issued by the 
user creating the check, sequentially ordered starting Jfrom 1 (for each user), and is representative 
of the position of the data string Q relative to other data strings, in an ordered succession of data 
strings Q (from that user). Preferably, Si is also representative of the order in time of the 
transaction Ti with respect to other transactions Ti, . . . , Ti-i, and Tj+i, . . . , Tn that that user has 
participated in with this merchant. 

In this form of the iuvention, the debit amount Du is determined using the serial number 
Si in each check contained in those lists selected for payment by the bank. In a case in which 
each transaction Ti has an equal value TV, the debit amount corresponding to a single check Q is 
given by: 

(SNi-Sx„ax.u)*TV, 

where Smax.u denotes the serial number appearing on the most recent check from the user U who 
produced Q that has so far been processed and selected for payment. A more detailed 
description is presented in the previous section HI, regarding the use of serial numbers on flie 
checks to eluninate the risk to the user of being charged in excess of what he actually spent. In 
other words, once the r lists of checks are selected for payment in this fourth embodiment, the 
checks may be processed individually similar to the way checks were processed in the third 
embodiment of this invention, assuming that the relevant selection probability is understood to 
be r/m. 

Figure 7 illustrates a system 300 for establishing payment for a plurality of n transactions 
Ti, T2, . . . , Ti, . . . , Tn, each Ti having a value TVi. The system 300 includes communications 
means for transmitting data between a user, a merchant, a bank, and a fourtih party. The system 
300 also includes a first processing means 310, a second processing means 320, a third 
processing means 330, and a fourth processing means 340. All four processing means typically 
include storage means 351 for storing data, input means 352 for mputtuig data, and a CPU 353 
that implements the system commands. 

The first processing means 310 is operative by a user for deriving, inputting, and storing 
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a data string Q (1 i n) for each Tj. The second processing means 320 is operative by 
merchant, and responsive to receipt of Q (i = 1, . . . n), for uniquely associating groups of said 
data strings Q (i = 1, . . . , n) into m lists L^(k = 1, . . . , m), and for inputting and storing said 
lists L^(k = 1, . . . , m). Each list includes data strings C^i, . . . , C^Iy^ and S"^k- 1 4 ^ n. The 
second processing means is further operative by the merchant for computing a commitment CM^ 
for each L^, and for inputting and storing the commitments CM^ (k = 1, . . . , m). 

The third processing means 330 is operative by the bank, upon receipt of the 
commitments CM^, for selecting one or more integer indices ii, ia, . . . , ir, and for causing the 
second party to receive the indices ii, 12, ... , ir, where 1 ^ ir < m for all r. The fourth processing 
means 340 is operative by the merchant, upon receipt of the indices ii, i2, . . • , i^ for de- 
committing CM, thereby revealing L*^ . . . , L^' to the bank. 

The system 300 includes means 370, operative by the third party upon revelation of . 
. . , L^^, for causing the user to be debited by a debit amoimt D and for causing a fourth party to 
receive a credit amount CR. 

In each of the proposed embodiments of this invention, tamper-resistant hardware such as 
smart cards or processors in cell phones may be used to provide security. 

In sum, methods and systems are featured in the present invention, which 1) eliminate the 
need for user-merchant interaction in the payment selection process; 2) incorporate time 
constraints into the system; 3) provide a selective deposit protocol which eliminates the risk of 
excessive charge to the user; and 4) provide a deferred selection protocol which provide the bank 
with flexibility and control over the payment process. 

While the invention has been particularly shown and described with reference to specific 
preferred embodiments, it should be understood by those skilled in the art that various changes in 
form and detail may be made therein without departing from the spirit and scope of the invention 
as defined by the appended claims. 
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CLAIMS 

1. A method of establishing pa3anent for a transaction T, the method comprising: 

A. a first party deriving firom T a data string C related to T, and causing a second party to 
receive at least a portion of said data string C; 

B. the second party associating with said at least a portion of C an item V, wherein V is 
substantially unpredictable by the first party; 

C. the second party determining whether V satisfies a property P, and if so, the second party 
causLog a third party to receive information I enabling the third party to verify whether V 
satisfies said property P; 

D. the third party, upon receiving I, verifyiag whether V satisfies said property P; and 

E. the third party causing a foxrrth party to receive an amount A, only if V satisfies said 
property P. 

2. A method according to claim 1 , wherein at least a portion of said data string C is 
authenticated. 

3. A method according to claim I, 

wherein the step of flie second party determining whether V satisfies a property P does . 
not require an interaction between the second party and the first party. 

4. A method according to claim 2, wherein said portion of said data string is authenticated 
by a fifth party on behalf of the first party. 

5 . A method according to claim 1 , wherein the step of the first party deriving the data string 
C firom T includes the step of the first party creating a digital signature for at least a portion of T, 
using a secret key of the first party. 

6. A method according to claim 5, wherein said digital signature of said first party 
comprises at least one of: 

(a) a deterministic signature; 

(b) a randomized signature; 

(c) an off-line signature; 

(d) an on-line signature; and 

(e) an identity-based signature. 
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7. A method according to claim 1, wherein the step of the second party associating the item 
V with C includes the step of the second party creating a digital signature for at least a portion of 
C, using a secret key of the second party. 

8. A method according to claim 7, wherein said digital signature of said second party is a 
deterministic signature. 

9. A method according to claim 1, wherein said data string C comprises at least one of: 
a digital signature for at least a portion of said transaction T, wherein said digital signature is 
computed using a secret key of the first party; 

a message authentication code, wherein said message authentication code value is computed 
using a secret key of the first party; and 
iii) an electronic check. 

10. A method according to claim 1, wherein said item V comprises at least one of: 

a) a digital signature for C, wherein said digital signature is computed using a secret key of 
the second party; and 

b) a message authentication code value, wherein said message authentication code value is 
computed using a secret key known to the second party. 

11. A method according to claim 1, wherein the step of said second party causing said third 
party to receive said information I includes at least one of: 

a) the second party sending I to the third party; 

b) the second party asking a fifth party to send I to the third party; and 

c) the second party posting I in a file, and said third party retrieving I firom said file. 

12. A method according to claim 1, fiirther including the step of the second party checking, 
after receiving C, the authenticity and integrity of C. 

13. A method according to claim 12, wherein the second party makes use of public 
verification information that is related to the first party, in order to check the authenticity and 
integrity of C. 
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14. A method according to claim 13, wherein said public verification information comprises 
the first party's public key that corresponds to the first party's secret key, in a public key digital 
signature scheme. 

15. A method according to claim 13, wherein the step of the second party making use of said 
public verification ioformation iacludes at least one of: 

(a) the second party obtaining said public verification ioformation fiom the first party; 

(b) the second party obtaioing said public verification information from information 
transmitted by the first party hi association with said data string C; 

(c) the second party obtaining said pubhc verification information from a digital certificate; 
and 

(d) the second party obtaining said pubhc verification information from infomiation about 
the first party that is publicly available. 

16. A method according to claim 1, wherein the second party and the fourth party are 
identical. 

17. A method according to claim 1 , wherein said second party and said third party are 
identical. 

18. A method accordmg to claim 1, whereui V satisfies P only if: 

F(V)<s, 

wherein F is fimction, and 
wherein s is a constant. 

19. A method according to claim 1 8, wherein 0 < s < 1 . 

20. A method according to claim 18, wherein F is a public fiinction that takes arbitrary bit 
strings as input, and returns as output a number greater than 0 and less than 1. 

21. A method according to claim 1 , wherein said transaction T is characterized in part by a 
transaction value Tv. 



22. 



A method according to claim 21, wherein said amount received by said fourth party is 
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23. A method according to claim 20, wherein said transaction T is characterized in part by a 
transaction value Tv, and wherein said amount received by said fourth party is equal to (Tv * 
1/s). 



24. A method according to claim 1, 

(a) wherein said item V comprises the digital signature of said second party relating to said 
data string C; and 

(b) wherein V satisfies said property P if F(V) is less than s, where F represents a public 
function that operates upon a bit string and returns as output a number between 0 and 1. 

25. A method according to claim 1, wherein said data string C contains information on T, 
said information comprising at least one of: 

a) the identity of the first party; 

b) the time of the transaction; and 

c) the date of the transaction. 

26. A method for a user U to establish payment to a merchant M for a transaction T having a 
transaction value Tv, the method comprising: 

A. the user establishing a public key and a corresponding secret key for a first digital 
signature scheme, and deriving firom T a data string C = SIGu(T) to create an electronic 
check containing C, wherein SIGu(T) represents the digital signature of the user U for the 
transaction T in said first digital signature scheme; 

B. the user causing the merchant to receive said data string C; 

C. the merchant establishing a public key and a corresponding secret key for a second digital 
signature scheme, and associating with said data string C an item V = SIGm(C), wherein 
SIGm(C) represents the digital signature of the merchant M for said data string C in said 
second digital signature scheme; 

D. the merchant computing the value F(V)=F(SIGm(C)), where F represents a public 
fimction that operates on a bit string to output a nimiber between 0 and 1; 

E. the merchant comparing F(SIGm(C)) with a constant s to determine whether F(V) < s, 
and if so, causing a bank to obtain said public key of the merchant; 

F. the bank using said pubUc key of the merchant to verify that F(SIGm(C)) <s; and 
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G. only if F(SIGm(C)) < s, the bank causing the merchant to receive an amount A = [Tv * 
1/s]; 

wherein s is a constant greater than 0 and less than 1, and represents the probability that 
the electronic check be selected for presentation to the bank. 

27. A system for establishing payment for a transaction T, the system comprising: 

A. communications means for transmitting data between a first party, a second party, a third 
party, and a fourth party; 

B. a first processing means operative by a first party for deriving, inputting, and storing a 
data string C related to T; 

C. a second processing means operative by a second party and responsive to C, for 
associatiag an item V with at least a portion of C, and for determining whether V satisfies 
a property P; 

wherein V is substantially unpredictable by the first party; 

D. means, selectively operative by the second party when V satisfies P, for causiag a third 
party to receive information I enabling the third party to verify whether V satisfies P; and 

E. means, selectively operative by the third party when V satisfies P, for causiag a fourth 
party to receive an amount A. 

28. A method of establishing payment for a transaction T, the method comprising: 

A. a first party receiving firom a second party at least a portion of a data string C, wherein 
said data stdbag C is related to T; 

B. the first party associating with said at least a portion of C an item V, wherein V is 
substantially unpredictable by the second party; and 

C. the first party determining whether V satisfies a property P, and only if so, the first party 
causing a third party to receive information I enabling the third party to verify whether V 
satisfies said property P, thereby enabling the third party to cause a fourth party to receive 
an amount A upon verification that V satisfies P. 

29. A method of establishing payment for a transaction T, the method comprising: 

A. a first party receiving from a second party information I enabling the first party to verify 
that an item V satisfies a property P; 

wherein said item V is associated with at least a portion of a data string C derived 
from T by a third party, and 
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wherein V is substantially unpredictable by said third party; 

B. the first party, upon receiving I, verifying whether V satisfies said property P; and 

C. the first party causing a fourth party to receive an amount A, only if V satisfies said 
property P. 



30. A method of establishing payment for a transaction T characterized in part by a time t, 
the method comprising: 

A. a first party deriving from T a data string C related to T, wherein C includes information 
IN regarding said time t; 

B. the first party causing a second party to receive at least a portion of said data string C, 
wherein said at least a portion of C includes inforoiation IN; 

C. the second party associating with said at least a portion of C an item V, wherein V is 
substantially unpredictable by the first party; 

D. the second party determining whether V satisfies a property P, and if so, the second party 
at time f causing a third party to receive information IN and information I enabling the 
third party to verify whether V satisfies said property P; 

E. the third party, upon receiving I, verifying whether V satisfies said property P; and 

F. the third party causing a fourth party to receive an amount A, only if: 

a) V satisfies said property P, and 

b) |t* - 1| is less than a predetermined time interval. 

31. A method accordiug to claim 30, wherein said predetermined time iuterval |t* - 1| is n 
days, where n is a nonzero integer firom about one to about seven. 

32. A method according to claim 30, wherein said predetermined time interval |t* - 1| is at least 
m hours, where m is a nonzero integer from about one to about twenty four. 

33. A method according to claim 30, wherein the first party in step B causes the second party 
to receive said portion of C at a time ti > t, 

and wherein the second party refiises to accept C as payment for T unless |ti - 1| is less 
than a predetermined amount. 

34. A method according to claim 30, 

wherein said data string C comprises a digital signature for at least a portion of T, created 
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35. A method according to claim 30, wherein V satisfies P only if V matches at least a 
portion of C. 

36. A method according to claim 30, wherein said property P depends on V but not on C. 

37. A method according to claim 30, wherein V satisfies P only if: 

F(V)<s, 
wherein F is a function, and 
wherein s is a constant and 0 < s < 1 . 

38. A method according to claim 37, wherein the value F(V) of the function F is substantially 
unpredictable by the first party. 

39. A method according to claim 37, wherein at least one of said fiinction F and said constant 
s are specified in C. 

40. A method according to claim 37, wherein F is one of: 

(a) a fixed public function; 

(b) a public fimction that takes arbitrary bit strings as input and returns as output a number 
greater than 0 and less than 1 . 

41 . A method according to claim 30, wherein V comprises a digital signature for C, 
computed using a secret key of the second party, and denoted as SIGm(C ). 

42. A method according to claim 30, further comprising , after the step of the fourth party 
receiving the amount A, the step of the third party causing the first party to receive a free 
subscription to one or more transactions TSi (i = 1, . . . , n) provided by the second party, if for all 
i (i = 1, . . . n), said transactions TSj are characterized in part by a time ts,-, and jts,- - 1| is less than 
a predetermined amount. 

43. A method according to claim 30, 

wherein said item V comprises a digital signature for at least one of: 
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a; aate intormaaon relating to i ana containea in c.; 

b) a serial number contained in C; 

c) a string included in C; 

d) a random string part of C; and 

e) a quantity dependent on C; 

and wherein V is computed using a secret key of the second party, and can be denoted as SIGm- 

44. A method according to claim 30, wherein said item V comprises a digital signature of 
G(C), where G represents at least one of a function and an algorithm. 

45. A method according to claim 44, wherein V satisfies P only if 

F(V)=F(SIGm(G(C)))<s; 
wherein F represents a function; 
wherein s represents a constant and 0 < s < 1 ; and 
wherein the value F(V) is substantially unpredictable by the first party. 

46. A method according to claim 44, wherein G(C) is specified within at least one of T and 
C. 

47. A method according to claim 44, wherein G(C) includes at least one of: 

(a) a substring of T; 

(b) information F regarding said time t of the transaction T; 

(c) information regarding the date on which the transaction T took place; and 

(d) a string W selected by the first party. 

48. A method according to claim 47, wherein said string W is unique to T, and is selected at 
random. 

49. A method according to claim 47, wherein V = SIGm(G(C)) is adapted to be computed by 
the second party before receiving said at least a portion of C. 

50. A method according to claim 44, wherem said property P is satisfied if at least some bits 
of V = SIGm(G(C)) match at least some bits of C. 
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51. A method according to claim 44, wherein said property P is satisfied if a selected m-bit 
string in V = SIGm(G(C)) matches a selected m-bit string in C, wherein m is a predetermined 
positive integer. 

52. A method according to claim 51, wherein m is about 10. 

53. A method of establishing payment for a transaction T, the method comprising: 

A. a first party deriving from T a data string C related to T, and causing a second party to 
receive at least a portion of said data string C; 

B. the second party deterroining whether a property P holds between said at least a portion 
of C and a quantity Q depending on C, wherein Q is substantially unpredictable by the 
first party, and if so, the second party causing a third party to receive information I 
enabling the third party to verify that said property P is satisfied; 

C. the third party, upon receiving I, verifying whether said property P is satisfied; and 

D. only upon verifying that said property P holds between said at least a portion of C and Q, 
the third party causing a fourth party to receive an amount A. 

54. A method according to claim 53, wherein said quantity Q can be represented as G(C), 
and wherein G is at least, one of a function and an algorithm. 

55. A method according to clahn 54, wherein G(C) includes information on at least one of; 

a) the time t at which the transaction T took place, and 

b) the date d on which the transaction T took place. 

56. A method according to claim 55, wherein said property P holds only if at least some bits 
of C equal at least some bits of SIGm(G(C)), where SIGm(G(C)) denotes the digital signature for 
G(C), created using a secret key of the second party. 

57. A method of establishing payment for a transaction T characterized in part by a time t, 
the method comprising: 

A. a first party deriving firom T a data string C related to T; 

B. a second party deriving a sequence of values VLi associated with a sequence of times ti (i 
= 1, . . . , n), wherein for at least one integer m greater than 1 and less than n, |t - tml is less 
than a predetermined amount; 
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C. the first party causing the second party to receive at least a portion of S2iid data string C, 
wherein said portion includes uiformation regarding the time t of said transaction T; 

D. the second party determining whether a property P holds between said portion of C, and 
one of said value VLm associated with tm, and a quantity Q depending on VLm; 

E. if P holds, the second party causing a third party to receive information I enabling the 
third party to verify that said property P is satisfied; 

F. the third party, upon receiving I, verifying whether Q satisfies P; and 

G. the third party causing a fourth party to receive an amount A, only if Q satisfies said 
property P. 

58. A method according to claim 57, wherein said quantity Q is given by: 

Q = F(SIGM(Vm)), where F represents a function, and where SIGmCVri) represents a digital 
signature of Vm, created using a secret key of the second party. 

59. A method of establishing payment for a transaction T characterized in part by a 
transaction t, the method comprising: 

A. a first party deriving from T a data string C related to T, wherein C includes information 

regarding t; 

B. a second party deriving a sequence of values Vi associated with a sequence of time units 
ti(i= 1, . . . ,n); 

wherein each pair of adjacent time units tj+i and ti defines a time interval 
Ati = tH-i-ti; and 

wherein for at least an integer m greater than 1 and less than n, said time t is 
within the time interval Atm; 

C. at the beginning of said time interval At^, the second party deriving, a value Qm associated 
with Vni, wherein Qm is substantially unpredictable by the first party; 

D. during said time interval Atn,: 

a) the first party causing the second party to receive at least a portion of C; 

b) the second party determining whether a property P holds between said portion of 
C and Qm, and if so, the second party causing a third party to receive information 
I enabling the third party to verify that said property P is satisfied; 

E. the third party, upon receiving I, verifying whether Q satisfies P; and 

F. the third party causing a fourth party to receive an amount A, only if Q satisfies said 
property P. 
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60. A method according to claim 59, wherein step C takes place before step B, and wherein 
said property P is satisfied only if at least some bits of Q match at least some bits of C, 

61. A method according to claim 59, wherein Qi is given by Qi = F(SIGM(Vi)), where F 
represents a function and where SIGM(Vi) represents a digital signature of Vi, created using a 
secret key of the second party. 

62. A method according to claim 59, whereia for all i = 1, . . . , n, the time interval 
Ati = I ti+i - ti I is a predetennined time interval. 

63. A method according to claim 62, wherein said predetermined constant is one day. 

64. A method of establishing payment for a transaction T characterized in part by a time t, 
the method comprisiag: 

A. a first party deriving from T a data string C related to T, wherein C includes information 

F regarding t; 

B. a second party deriving a sequence of values Xi (i = 0, 1, . . . , n) associated with a 
sequence of time values ti (i = 0, 1, . . . , n), and making xo public; 

wherein Xi = H(Xi+i) for i = 0, 1, . . . , n-1, where His a one-way hash function; 
wherein each pair of adjacent time values ti+i and tj defines a time interval Ati= ti+i - tj; 
and 

wherein for at least an integer m greater than 1 and less than n, said time t is the time 
interval Atm; 

C. during said time interval Atm, the first party causing the second party to receive at least a 
portion of C, wherein said portion includes F; 

D. during said time interval At^, the second party determining whether a property P holds 
between Qm and said portion of C, and if so, the second party causiug a third party to 
receive information I enabling the third party to verify that said property P is satisfied; 

E. the third party, upon receiving I, verifying whether Qm satisfies P; and 

F. the third party causing a fourth party to receive an amoimt A, only if Q satisfies said 
property P. 



65. A method according to claim 64, wherein the step of the second party making Xq public 
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comprises at least one of: 

a) placing Xq in a public file; and 

b) digitally signing xo using a secret key of the second party, and placing the corresponding 
public key in a public directory; 

66. A method according to claim 64, whereia said time iaterval Ati = tj+i - ti is a 
predetermined constant for all i = 1, . . . , n. 

67. A system for establishing payment for a transaction T characterized in part by a time t, 
the system comprising: 

A. commxmications means for transmitting data between a first party, a second party, a third 
party, and a fourth party; 

B. a first processing means operative by a first party for deriving, inputting, and storing a 
data string C related to T, wherein C contains information F regarding the time t; 

C. a second processing means operative by a second party and responsive to C, for 
associating an item V with at least a portion of C, and for determining whether V satisfies 
a property P; 

wherein V is substantially unpredictable by the first party; 

D. means, selectively operative by the second party when V satisfies P, for causing a third 
party to receive F, and infomiation I enabling the third party to verify: 

a) whether V satisfies P; and 

b) wherein |t' - 1] is less than a predetermined amount; 

E. means, selectively operative by the third party when V satisfies P, and |t' - 1| is less than a 
predetermined amoimt, for causing a fourth party to receive an amount A. 

68. A method of establishing payment for a transaction T characterized in part by a time t, 
the method comprising: 

A. a first party receiving firom a second party at time t' information I enabling the first party 
to verify that an item V satisfies a property P; 

wherein said item V is associated with at least a portion of a data string C that is derived 
firom T by a third party and that includeis information regarding t; and 
wherein V is substantially unpredictable by said third party; 

B. the first party, upon receiving I, verifyrag whether V satisfies said property P; and 

C. the first party causing a fourth party to receive an amount A, only if: 
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a) 
b) 



V satisfies said property P; and 

•'|t' - ti is less than a predetennined amount. 
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69. A method of establishing payment for a transaction T characterized in part by a time t, 
the method comprising: 

A. a first party receiving firom a second party at least a portion of a data string C, wherein 
said data string C is related to T, and wherein said portion of C includes information on t* 

B. the first party associating with said at least a portion of C an item V, wherein V is 
substantially unpredictable by the second party; and 

C. the first party determining whether V satisfies a property P, and if so, the first party at a 
time t' causing a third party to receive infonnation I enabling the third party to verify 
whether V satisfies said property P, thereby enabling the third party to cause a fotirth 
party to receive an amoimt A, provided that 

a) V satisfies P; and 

b) 1 1* - 1 1 is less than a predetermined amount. 

70. A method of establishing payment for a plurality of n transactions Ti, T2, . • • Ti, . . . Tn, 
wherein an index i, between 1 and n, can be associated with each Ti, and wherein each 
transaction Ti is characterized in part by a transaction value TVj, the method comprising: 

A. a first party using a probabilistic payment scheme to generate a check Ci for each 
transaction Ti and causing a second party to receive said Q, wherein Q mcludes an 
indication of the index i; 

B. the second party selecting the checks Q (1 < j < n ) that are payable in a manner that 
prevents the first party from predicting in advance which checks Q will be selected to be 
payable; 

C. the second party causing a third party to receive information Ij enabling the third party to 
verify that a selected check Q is payable; 

D. the third party, in response to receipt of Ij, verifying that a selected check Cj is payable; 
and 

E. only if Q is payable, a fifth party causing a fourth party to receive a credit amount CRj, 
and causing the first party to be debited by a debit amo\mt Dj so that, for all index j 
between 1 and n, and for any selection of payable checks, D=Di+D2+...+Dj is no greater 
than TVagg = TVi + TV2 + . . . +TVj. 
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71 . A method according to claim 70, wherein each debit amount Dj is determined at least in 
part by one of TVj and Q, for all index j between 1 and n. 



72. A method according to claim 70, wherein each debit amoimt Dj depends on said index j 
associated with Tj. 

73. A method according to claim 72, wherein each debit amount Dj also depends on at least 
one of a previous debit amount Dk (1 ^ k < j < n), and a previous index / (1 < / < j < n)for which 
a debited amount D/ was debited. 

74. A method accordtag to claim 70, further comprising the step of said fifth party . causing an 
indication of the index j to be stored, for each check Cj selected for payment. 

75. A method accordiag to claim 74, wherein each debit amount Dj of a payable check Q 
depends on the latest stored index k of any previous checks found to be payable. 

76. A method according to claim 70, wherein the step of the second party causing the third 
party to receive the information Ij includes at least one of: 

a) the second party sending Ij to the third party; 

b) the second party asking a fifth party to send Ij to the third party; and 

c) the second party posting Ij in a file, and said third party retrieving Ij firom said file. 

77. A method of estabUshing payment for aplurahty of n transactions Ti, T2, . . . Ti, . . . Tn, 
wherein an index i, between 1 and n, can be associated with each Ti, and wherein each 
transaction Ti is characterized in part by a transaction value TVi, the method comprising: 

A. a first party deriving from each transaction Tj a data string Q related to Ti, and causing a 
second party to receive said data string Ci; 

B. the second party associating with each data string Q an item Vi, wherein Vi is 
substantially unpredictable by the first party; 

C. the second party determining whether Vi satisfies a property Pi, and if so, the second 
party causing a third party to receive information li enabling the third party to verify 
whether Vi satisfies said property Pi; 

D. the third party, in response to receipt of li, verifying whether Vi satisfies said property Pi; 
and 
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E. only if Vi satisfies said property Pi, a fifth party causing a foTirth party to receive a credit 
amount CRi, and causing the first party to be debited by a debit amount Dj; 

wherein said debit amount Di is less than or equal to said credit amount CRi. 

78. A method according to claim 77, wherein Di + D2 + . . . + Dj is less than or equal to TVi 
+ TV2 + . . . + TVi, for all index i between 1 and n. 

79. A method according to claim 77, whereki each debit amount Di is determined at least ia 
part by one of TVi and Q, for all index i between 1 and n. 

80. A method according to claim 77, wherein each data string Ci contains an indication of 
said index i associated with Ti. 

81. A method according to claim 80, wherein each debit amount Di depends on said index i 
associated with Ti. 

82. A method according to claim 81, wherein each debit amount Di also depends on at least 
one of a previous debit amount Dj, and a previous index k for which a debited amount Dk was 
debited. 

83. A method according to claim 82, wherein Di + D2 + . . . + A is less than or equal to TVi 
+ TV2 + . . . + TVi, for all index i between 1 and n, 

84. A method according to claim 77, further comprising the step of said fifth party causing 
infoimation SNi to be stored for each data string Q whenever Vi satisfies Pi. 

85. A method according to claim 84, wherein SNi is a progressive serial number 
representative of an order of said data string Q relative to flie other data strings 

Ci . . . Ci-i and Ci+i . . . Cn ta an ordered succession of data strings derived by said first 

party. 

86. A method according to claim 84, wherein each debit amount Di is determined using SNi. 

87. A method according to claim 84, wherein Di + D2 + . . . + Di is less than or equal to TVi 
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+ TV2 + . . . + TVi, for all index i between 1 and n. 
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88. A method according to claim 84, wherein each debit amount Dj is determined using SNi. 

89. A method of paying for a plurality of equal-valued transactions Ti, T2, . . . Ti, . . . Tn, 
each having a value TV, the method comprising: 

A. a first party deriving fi*om each transaction Ti a data string Q related to Ti, and causing a 
second party to receive said data string C,-; 

wherein each data string Cj comprises a progressive serial number Si, said serial number 
Si being sequentially ordered starting from 1 and being representative of a position of Q 
relative to other data strings in an ordered succession of data strings Cj (j = 1, . . . , n); 

B. the second party associating with Cj an item Vi, wherein Vi is substantially unpredictable 
by the first party; 

C. the second party determining whether a property Pi holds between Ci and Vi, and if so, 
the second party causing a third party to receive information Ii enabling the third party to 
verify whether Vi satisfies Pi; 

D. the third party verifying whether Vi satisfies P^; and only if Vi satisfies Pj: 

a) a fifth party determining the value of Smax, wherein Smax represents the largest of 
any serial number Sk contained in Ck for which: 

i) 1 k<n; 

ii) Ck is received by second party before receiving C^; 

iii) the third party has verified that Vk satisfies Pk; and 

iv) said first party has been debited by a nonzero amount Dk; 

b) said fifth party causing a fourth party to receive a credit amoimt CR; and 

c) said fifth party causing the first party to be debited by a debit amount Di, where Di 
is given by: 

( Si- Smax) * TV. 

90. A method according to claim 89, wherein Vi satisfies Pi only if: 

F(Vi)<s, 

wherein s is a number, and F is a function that operates on a bit string and returns a 
number. 

91 . A method according to claim 90, wherein said credit amount CR received by said fourth • 
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party is proportional to TV and to 1/s. 
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92. A method according to claim 90, wherein F is a function that operates on a bit string to 
output a number between 0 and 1, and wherein s is a number between 0 and 1 . 

93. A method for a user U to estabUsh payment to a merchant M for a plxiraUty of 
transactions Ti (i = 1, . . . , n) having transaction values TVj (i = 1, . . . , n), the method 
comprising: 

A. the user U establishing a public key and a corresponding secret key for a first digital 
signature scheme, and deriving from each Ti a data string Ci = SIGu(Ti) and creating an 
electronic check CHj that contains d and a serial number Sj; 

wherein SIGu(Ti) represents the digital signature of the user Ui for the transaction Ti in 
said first digital signature scheme; 

wherein Sj is a progressive serial number representative of an order of said data string Q 
relative to the other data strings in an ordered succession of data strings Q 0 = 1> • • • » ii) 
derived by said first party; 

B. the user U causing the merchant M to receive said electronic check CHf containing Cj and 
Si; 

C. the merchant M establishing a public key and a corresponding secret key for a second 
digital signature scheme, and associating with said data string Cj an item Vi = SIGM(Ci)j 
wherein SIGM(Ci) represents the digital signature of the merchant M for said data string 
Ci in said second digital signature scheme; 

D. the merchant M computing the value F(Vi)=F(SIGM(Ci)), where F represents a public 
function that operates on a bit string to output a number between 0 and 1 ; 

E. the merchant M comparing F(SIGM(Ci)) with a constant s (0 < s < 1) to determine 
whether F(Vi) < s, and if so, causing a bank to obtain said pubhc key of the merchant M; 

F. the bank using the merchant's public key to verify that F(SIGM(Ci)) <s; and 

G. only if FCSIGmCQ)) < s, 

a) a fifth party determining the value of Smax, wherein Smax represents the largest 
serial number Sj contained in any CHj in said ordered succession upon which 
payment was made; 

b) said fifth party causing a fourth party to receive a credit amount CR; and 

c) said fifth party causing the first party to be debited by a debit amount Di. 
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94. A method according to claim 93, wherein each transaction Tj (i = 1, . . . , n) is equal- 
valued so that TVi = TV for all i = 1, , . . , n, and wherein Di is given by: 

Di = (Si.Sn^)*TV; 

and wherein CR is given by: 

CR = TV*(l/s). 

95. A system for estabUshing payment for a plurality of n transactions Ti, T2, . . . , Tj, . . . , 
Tn, wherein an index i, between 1 and n, can be associated with each Ti, and wherein each 
transaction Ti is characterized in part by a transaction value TVi, the system comprising: 

A. communications means for transmitting data between a first party, a second party, a third 
party, and a fourth party; 

B. a first processing means operative by a first party for deriving, inputting, and storing a 
data string Ci (i less than or equal to n and greater than or equal to 1), 

wherein Ci is related to a transaction Ti, and 

wherein Ci includes a progressive serial number Si representative of the 
position of the check Ci relative to other checks in an ordered succession of checks Cj Q 
= 1, . . . , n); 

C. a second processing means operative by a second party and responsive to Ci, for 
associating an item Vi with at least a portion of Ci, and for determining whether„Vi 
satisfies a property Pi, 

wherein Vi is substantially unpredictable by the first party; and 
wherein said second processing means are selectively operative by the 

second party, when Vi satisfies Pi, for causing a third party to receive information li 

enabling the third party to verify whether Vi satisfies Pi; and 

D. means, selectively operative by the third party when Vi satisfies Pi, for determi n i n g the 
value of Smax, for causing a fourth party to receive an amount CRi, and for causing the 
first party to be debited by an amount Di, wherein for aU index i between 1 and n, Di + 
D2 + . . . + Di is no greater than TVi + TV2 + . . . + TVs. 

96. A method of establishing payment for a plurality of n transactions Ti, T2, . . . , Ti, . . . , 
Tn, wherein an index i, between 1 and n, can be associated with each Tj, and wherein each 
transaction Tj is characterized in part by a transaction value TVj, the method comprising: 
A. a first party receiving firom a second party at least a portion of a data string Ci for each Ti, 
wherein each data string Ci is generated firom Ti using a probabilistic payment scheme. 
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and wherein each Ci includes an indication of the index i; 

B. the first party selecting the checks Cj Q less than or equal to n and greater than or equal to 
1) that are payable ia a manner that prevents the first party from predicting in advance 
which checks Cj will be selected as payable; 

C. for each selected check Cj, the first party causing a third party to receive information Ij 
enabling the third party to verify that the selected check Cj is indeed payable, thereby 
enabling the third party, upon verification that Cj is payable, to cause a fourth party to 
receive a credit amount CRj and the second party to be debited by a debit amount Dj so 
that, for all index j between 1 and n, and for any selection of payable checks Cj, D = Di + 
Da + . . . Pj is no greater than TVagg = TVi + TV2 + . . . + TVj. 

97. A method of establishing payment for a plurality of n transactions Ti, T2, . . . , Tj, . . . , 
Tn, wheretu an index i, between 1 and n, can be associated with each Ti, and wherein each 
transaction Tj is characterized in part by a transaction value TVi and can be represented by a 
correspondiug data string Ci, the method comprising: 

A. a first party receiving fiom a second party information 1^ enabling the first party to verify 
that a check Cj is payable; 

wherein said check Q is selected by the second party firom a plurality of checks Ci (i = 1, . . . , n) 
derived by a third party from a corresponding one of said plurality of transactions Ti (i = 
1,. . .,n); and 

wherein the selection of said check Cj is substantially unpredictable by said third party; 

B. the first party, upon receiving Ij, verifying whether Cj is indeed payable; and 

C. the first party causing a fourth party to receive a credit amount CRj, and causing the third 
party to be debited by a debit amount Di, 

98. A method of establishing payment for a plurality of n transactions Ti, T2, . . . Tj, . . . Tn, 
wherein each transaction Ti is characterized in part by a transaction value TVi that is a m\iltiple 
of a unit value UV, the method comprising: 

A. a first party deriving from each transaction Tj a data string Cj corresponding to Tj, and 

causing a second party to receive Q; 
wherein each data string Q includes informatiori on said integer index i and said value TVj of Ti 

in the form of a vector (Si. Si + Vi-1); 
wherein for all i between 1 and n. Si is a progressive serial number that is sequentially ordered 

and that is representative of a position of d relative to other data strings in an ordered 
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succession of data strings Cj (j = 1, . . . , n); and 
wherein is an integer depending on i and indicative of the value TVj of Tj, and is given by Vj = 
TV./(UV); 

B. the second party selecting the checks Cj (1 ^ j < n ) that are payable in a manner that 
prevents the first party firom predicting in advance which checks Q will be selected to be 
payable; 

C. the second party causing a third party to receive information Ij enabling the third party to 
verify that a selected check Cj is payable; 

D. the third party, in response to receipt of Ij, verifying that a selected check Cj is payable; 
and 

E. only if Cj is payable: 

a) a fifth party deterroining the value of Smax, 

wherein max is an integer such that 1 < max < i < n, and Vmax = TVmax / (UV); and 
wherein Smax represents the largest of any serial number Sk (1 ^ k < n) contained 
in Ck for which: 

i) Ck is received by the second party before receiving Q; and 

ii) the third party has verified that Vk satisfies Pk; and 

iii) said first party was debited by a non-zero amoimt Dk. and 

b) said fifth party causing a fourth party to receive a credit amount CR; and 

c) said fifth party causing the fijst party to be debited by a debit amount Di, where Di 
is given by: 

(Si + Vi-l-S„«x)*UV. 

99. A method of establishing payment for a plurality of n transactions Ti, T2, . . . Ti, . . . Tn, 
wherein an index i between 1 and n is associated with each Tj, and wherein each transaction Ti is 
characterized in part by a transaction value TVi that is an integral multiple of a unit value UV, 
the method comprising: 

A. a first party deriving>from each transaction T,- a data string Q corresponding to Tj and 
causing a second party to receive Q; 

wherein each data string Q includes information on said integer index i and said value 
TVi of Ti in the form of a vector (Si, Si + Vj - 1); 

wherein for all i between 1 and n. Si is a progressive serial number that is sequentially 
ordered and that is representative of a position of Cj relative to other data strings in an 
ordered succession of data strings Cj (j = 1, . . . , n); and 
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wherein Vi is an integer depending on i and indicative of the value TVi of Ti, and is given 
byVi = TVi/(UV); 

B. the second party associating with Q an item Vj, wherein Vj is substantially unpredictable 
by the first party; 

C. the second party determining whether a property Pj holds between Q and Vi, and if so, 
the second party causing a third party to receive information li enabling the third party to 
verify whether Vj satisfies Pi; 

the third party verifying, whether Vj satisfies Pj; 
and only if Vi satisfies P^: 

a) a fiilh party determining the value of Smax? 

wherein max is an integer such that 1 < max < i < n, and Vmax = TVmax / (UV); and 
wherein Smax represents the largest of any serial number Sk (1 ^ k < n) contained in Ck for 
which: 

i) Ck is received by the second party before receiving Q; and 

ii) the third party has verified that Vk satisfies Pk; and 

iii) said first party was debited by a non-zero amount Dk, and 

b) said fifth party causing a fourth party to receive a credit amount CR; and 

c) said fifth party causing the first party to be debited by a debit amount Dj, where Di 
is given by: 

(Si + Vi-l-S„^)*UV. 

100, A method of establishing payment for a plurality of n transactions Ti (i = 1 , . . . , n), each 
transaction Ti having a value TVi, the method comprising: 

a. a first party deriving firom each Ti a data string Ci related to Ti, and causing a second 
party to receive said data string Q; 

b. the second party uniquely associating groups of said data strings Q (i = 1, . . . , n) into 
m lists L^, where k = 1, . . . , m; 

wherein each list L*^ includes data strings C^^i, . . . , C'^/k, and 
wherein S™k=:i/k= n; 

c. the second party committing to (k = 1, . . . , m), by computing a commitment CM^ for 
each L^ and causing a third party to receive CM'^ (k = 1, . . . , m); 

d. the third party, in response to receipt of CM^ (k = 1 , . . . , m), selecting one or more 
integer indices ii, i2, - . . ir, causing the second party to receive said indices iu 12, . . • 
ir. wherein 1 < if ^ m; 

69 



wo 02/088874 PCTAJS02/12189 
e. in response to receipt of said indices ii, ia, . . . ir, the second party de-committing CM'^ 

CM^. . . CM}\ thereby revealing V\ . . to the third party; and 
£ a fifth party causing a fourth party to receive a credit amount CR, and causing the first 
party to be debited by a debit amount D. 

101 . A method according to claim 100, wherein said commitment CM^ for is a hash value 
H(L^), and wherein H is a one-way hash function. 

102. A method according to claim 100, wherein each data string Q includes one or more bits 
that represent said transaction value TVi. 

103. A method according to claim 102, fiirther comprising the step, after step (b), of the 
second party associating with each list a corresponding value V\ wherein represents the 
aggregate value of all the data strings C^i, . . . , C\ in list L\ 

wherein V*^ is given by 

V^ = TV\ + ... + TV^/k. 

104. A method according to claim 103, fiirther comprising the step, after step (c) , of the 
second party computing a commitment CV for the list of values (V\ . , V™), 

wherein said commitment CV commits the second party to (V\ . . V^, 
wherein CV is a hash value H(V^ . . V"^ ; and 

wherein H is a one-way hash fimction, so that by de-committing CV, the second party 
reveals (V\ . . ., V"^ to the third party. 

105. A method according to claim 100, wherein said credit amount CR received by the fourth 
party is given by: 

V = v' + .. . + V'' + . S"'lc-lV^ 

106. A method according to claim 100, wherein said debit amount D is given by: 

D = V" + V*^ + . . . + V*' multiplied by a scale factor. 

107. A method according to claim 106, wherein said scale factor is m/r. 



108. A method according to claim 100, wherein said each data string Q includes information 
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representative of an integer SNi, wherein SNi is a progressive serial number sequentially ordered 
starting from 1 , and wherein said serial number SNi is representative of the order in time of said 
transaction Ti with respect to other transactions Ti, . . . , Tm and Ti+i, . . . .Tnin said plurality of 
n transactions Ti (i = 1, . . n). 

109. A method according to claim 100, wherein the step of the Gist party deriving said data 
string Ci from Tj includes the step of the first party creating a digital signature for at least a 
portion of Ti, using a secret key of the first party. 

110. A method according to claim 100, wherein at least a portion of Ci is authenticated. 

111. A method according to claim 100, wherein Q comprises at least one of: 

a) a digital signature for at least a portion of T; 

b) a message autiientication code; and 

c) an electronic check. 

1 12. A method accordmg to claim 100, wherein said fifth party and said third party are 
identical. 

113. A method according to claim 100, wherein said second party, said third party, and said 
fifth party are identical. 

1 14. A method according to claim 100, wherein said second party and said third party are 
identical. 

115. A method of establishing payment for a plurality of n transactions Ti, . . . , Ti, . . . , Tn, 
each transaction Ti having a value TVi, the method comprising: 

A. for each Ti, a first party receiving from a second party a data string Q derived from Ti; 

B. the first party uniquely associating groups of said data strings Q (i = 1, . ■ • » n) into m 
lists where k = 1, . . . , m; 

wherein each hst L^. includes data strings C^i, . . . , C^/k, and 
wherein 2)"^k= i ~ n; 

C. the first party committing to (k = 1, . . . , m), by computing a commitment CM^ for 
each L^, and causing a third party to receive CM^ (k = 1, . . . , m), thereby enabUng the 
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third party to select one or more integer indices ii, i2, . . . ir, wherein 1 < ir < m; 
D. upon receipt of said indices ii, ia, . . . ir, the first party de-conimitting CM'S CM^^. . . 

CM^^ thereby revealing , . ., L**^ to the third party and enabling the third party to cause 
a fourth party to receive a credit amount CR, and the second party to be debited by a 
debit amount D. 

116. A method of establishing payment for a plurality of n transactions Ti, . . . , T^, . . . , Tn, 
wherein each transaction Ti has a value TYi and can be represented by a corresponding data 
string Ci derived from Tj, and wherein groups of said data strings Q (i = 1, . . . , n) can be 
uniquely associated into m Usts (k = 1 , . . . , m), each list includes data strings C^i, . . . , 
C\ (S^^k^ 1 Ik = the method comprising: 

A. a first party receiving from a second party a commitment CM^ for each of the m lists Lk 
(k=l, . . . ,m); 

B. the first party, upon receiving CM^ (k = 1, . . . , m), selecting one or more integer indices 
iw i2, . . . ir, wherein 1 < ir < m, and causing the second party to receive said indices ii, i2j . 
. . ir, thereby enabling the second party to de-commit CM'\ CM'^. . . CM*' so as to 
revealing L'\ . . L'' to the first party; 

C. the first party causing a third party to receive a credit amount CR, and a fourth party to be 
debited by a debit amount D. 

117. A system for establishing payment for a plurality of n transactions Ti, T2, ■ . . ,'Ti, . . . , 
Tn, each Ti having a value TV,, the system comprising: 

A. communications means for transmitting data between a first party, a second party, a third 
party, and a fourth party; 

B. a first processing means operative by a first party for deriving, inputting, and storing a 
data string Q ( 1 ^ i < n) for each Ti; 

C. a second processing means operative by a second party and responsive to receipt of Q (i 
= 1, . . . n) , for imiquely associating groups of said data strings Q (i = 1, . . . , n) into m 
lists L'^ (k = 1, . . . , m), and for inputting and storing said lists L^^Ck = 1, . . . , m); 
wherein each list includes data strings C^i, . . . , C^/k, and 

wherein I /k= n; 

said second processing means being further operative by the second party for computing 
a commitment CM^ for each L^ and for inputting and storing said commitments CM^ (k 
= 1, . . . , m); 
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a third processing means, operative by the third party upon receipt of said commitments 
CM^ for selecting one or more integer indices ii, ii, . . . , ir. and for causing the second 
party to receive said indices ii, ii, . . . , ir» 
wherein 1 < if < m for all r; 

a fourth processing means, operative by the second party upon receipt of said indices ii, 
ia, . . . , ir, for de-committing CM, thereby revealing to the third party; and 
means, operative by the third party upon revelation of . . . , U^, for causing the first 
party to be debited by a debit amount D and for causing a. fourth party to receive a credit 
amount CR- 
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